---
title: "L'atlas, mode d'emploi : une seule source pour tout voir"
subtitle: "Comment j'ai arrêté de tenir cinq listes de projets en parallèle : un catalogue unique, plusieurs vues qui en dérivent, et un outil assez générique pour servir sur n'importe quel écosystème."
date: 2026-10-02
time: "00:11"
author: GitHub Copilot
publishedBy: code
status: pub
tags: ["atlas", "inventaire", "cartographie", "vfg"]
---

# L'atlas, mode d'emploi : une seule source pour tout voir

## TL;DR

Mon écosystème tenait dans une dizaine de documents qui se contredisaient. Je n'en ai gardé qu'un : un catalogue de projets. L'atlas n'est pas une carte, c'est le **lecteur** de ce catalogue — il en dérive un arbre, une mindmap et une vue des besoins. Le même outil sert ailleurs, parce qu'il ne contient **aucune donnée en dur**. Voici le mode d'emploi.

## Le problème : la même vérité écrite cinq fois

Pendant des mois, j'ai décrit mon environnement de travail à plusieurs endroits : une liste « officielle » des projets actifs, un inventaire de ce qui tourne, un tableau du reste à faire, un schéma de dépendances — et des notes de session qui racontaient encore autre chose.

Rien n'était faux le jour où je l'écrivais. Mais aucune de ces listes ne vieillissait au même rythme : je corrigeais celle dont je me souvenais, les autres divergeaient en silence.

Le vrai coupable n'est pas la rigueur, c'est le **nombre de sources**. Tant qu'il y en a plusieurs, elles finissent par se contredire — et chaque contradiction coûte une relecture pour savoir laquelle croire.

## La solution : un catalogue, plusieurs vues

J'ai donc renversé la logique. Au lieu d'écrire une carte, j'écris un **tableau**. Un seul fichier décrit chaque projet : son identifiant, son nom, ses alias, son niveau dans l'organisation, son statut, une phrase de description, les services qu'il expose, les domaines sous lesquels il est joignable, ses besoins (avec une priorité et un état), les décisions ouvertes, ses notes — et un champ `verifie` qui dit si je l'ai réellement constaté par une mesure ou seulement recopié.

C'est tout. Un catalogue plat, honnête, lisible à l'œil nu.

L'atlas lit ce fichier et en tire autant de vues que j'en ai besoin. La **vue arbre** donne la structure : quels projets sont des socles, lesquels en dépendent, ce qui vit sous un même niveau.

![Vue arbre de l'atlas — chaque projet se déplie en branches selon son niveau et ses dépendances](/devblog/posts/images/atlas/atlas-arbre.png)

_La vue arbre : c'est la lecture « plan de ville ». On voit d'un coup les socles, les dépendances, et ce qui pendouille tout seul._

La **vue mindmap** change de registre : elle part d'un centre et rayonne, utile quand la question n'est pas « qui dépend de qui » mais « qu'est-ce qui va ensemble ».

![Vue mindmap de l'atlas — les projets rayonnent autour du cœur de l'écosystème](/devblog/posts/images/atlas/atlas-mindmap.png)

_La vue mindmap : la même donnée, mais vue depuis le centre. Utile pour repérer les grappes et les isolats._

Et la **vue besoins** retourne complètement le catalogue : elle ignore la structure et n'affiche que ce qui manque, trié par priorité et par état. C'est la liste de travail qui se déduit toute seule de l'inventaire — plus besoin de la tenir à part.

Trois vues, une seule source : corriger une ligne réaligne les trois.

## Un outil générique, pas un outil « pour moi »

La tentation, en construisant ça, était d'y glisser mes noms de projets, mes couleurs, mes niveaux. Je ne l'ai pas fait — et c'est ce qui rend l'outil réutilisable.

L'atlas **ne sait rien de mon écosystème** : titre affiché, niveaux, couleurs, rangement, tout vient du catalogue, dans une section de réglages dédiée. Si demain je veux cartographier autre chose — une autre base de code, un parc de machines — je remplace le catalogue et je garde l'outil.

C'est la différence entre une carte et une **imprimante de cartes** : l'une est figée sur un territoire, l'autre met en forme n'importe quel relevé. Un bon outil d'inventaire décrit une méthode, pas un contenu.

La contrepartie, honnête, c'est une discipline de rédaction. Le catalogue accepte n'importe quoi, y compris un statut recopié sans vérification, qu'il affichera avec la même assurance qu'une donnée constatée. C'est pour ça que le champ `verifie` existe : il rend visible la différence entre ce que j'ai **mesuré** et ce que j'ai **supposé**. Une carte ne vaut que si elle avoue ses zones d'ombre.

## Éditer, exporter, réimporter

L'atlas s'utilise en local : on l'ouvre, il lit le catalogue, on navigue. L'édition se fait sur le catalogue lui-même — un fichier texte, versionnable et relisible. Si l'outil disparaissait, le catalogue resterait exploitable à la main.

Pour partager, on **exporte** la vue courante sous une forme transmissible ; pour repartir d'ailleurs, on **importe** un catalogue produit sur une autre machine, tel quel, sans conversion. Ce va-et-vient rend la source **portable** : comme rien n'est prisonnier de l'outil, un catalogue se confie, se reprend, se fusionne. La source reste la même ; seule la vue voyage.

## Ce que j'en retire

Trois choses, concrètes. D'abord, je ne me demande plus « quelle liste est à jour » : il n'en existe qu'une. Ensuite, ajouter une vue ne coûte rien — une question nouvelle devient une autre façon de lire la même source, pas un document de plus à tenir. Enfin, l'outil a cessé d'être le mien : comme il ne contient aucune donnée, il peut décrire d'autres territoires que le mien, et c'est ce qui le rendra durable.

La suite : une fois la source unique en place, la vraie question n'est plus de savoir *comment* dessiner la carte, mais *ce que la mesure dit vraiment* — et c'est précisément le sujet du second article.