Vingt ans, de l'infrastructure à l'écran

La mesure du travail invisible, c'est qu'on ne le juge que lorsqu'il lâche. Vingt ans durant je l'ai appris ; puis je suis passé du côté visible.

Les carrières paraissent nettes après coup. Elles ne le sont pas quand on les vit : chaque période commence par un problème que la précédente n'a pas su résoudre.

Ce texte parle de quatre périodes. Mais ce n'est pas un CV — il parle de l'habitude qui s'est révélée utile dans la couche suivante et de celle qu'il a fallu abandonner.

2005–2013 — Infrastructure d'entreprise

Serveurs, stockage, sauvegarde, continuité.

Si cette période a enseigné une chose, c'est celle-ci : un système qui marche est invisible tant qu'il marche. Les sauvegardes n'entrent à l'ordre du jour de personne pendant des années. Puis un jour on en a besoin, et ce jour-là est l'examen de tout ce qui a été fait jusque-là.

La conséquence professionnelle est étrange. Un travail d'infrastructure bien fait ne produit pas d'éloges, seulement du silence. L'éloge n'arrive que lorsque quelque chose lâche et que la reprise est rapide — autrement dit, votre moment le plus visible est votre pire journée.

L'habitude emportée : écrire le scénario de reprise avant l'installation. La première question quand on bâtit un système n'est pas « comment cela va-t-il marcher » mais « comment revenons-nous quand cela casse ». Qu'une sauvegarde existe ne suffit pas ; la restauration doit avoir été répétée. Une sauvegarde non testée n'est pas une sauvegarde.

2013–2019 — Réseaux et sécurité

Routage, pare-feu, accès.

Le travail réseau apprend à voir un système comme une topologie. Non pas des boîtes isolées mais les relations entre elles. Où passe un paquet, quelle règle l'arrête, pourquoi un chemin est préféré à un autre.

La leçon la plus durable de cette période ne porte pas sur la sécurité mais sur la visibilité : la condition préalable pour résoudre un problème est de pouvoir le voir. La plupart des pannes réseau ne sont pas mystérieuses ; elles sont seulement non mesurées. Placez un compteur au bon endroit et le mystère se dissipe.

La deuxième leçon porte sur les valeurs par défaut. Les règles de pare-feu s'accumulent avec le temps ; chacune a servi une fois, aucune n'a jamais été retirée. Cinq ans plus tard, personne ne sait expliquer toute la liste. Une équipe qui n'écrit pas pourquoi une règle existe ne pourra jamais l'effacer.

C'est pourquoi les commentaires de code que j'écris aujourd'hui expliquent « pourquoi c'est ainsi », non « ce que ça fait ». Ce que ça fait est déjà dans le code.

2019–2024 — Identité et M365

Active Directory, migrations, identité cloud. De l'ordre à l'échelle de milliers de comptes.

Le travail sur l'identité est une leçon d'échelle. Dix comptes, vous les gérez à la main. À des milliers, tout ce qui est fait à la main se transforme tôt ou tard en incohérence — car le travail manuel n'est pas reproductible.

L'habitude emportée : une exception n'est pas une solution, c'est une dette. Une règle spéciale ouverte pour un utilisateur reste dans le système longtemps après son départ. À l'échelle, la bonne réponse n'est pas d'enregistrer l'exception mais de réécrire la règle pour que l'exception devienne inutile.

Les projets de migration ajoutent leur propre leçon : une migration sans plan de retour n'est pas une migration, c'est un pari. Et le plan de retour doit être répété avant la migration, pas après.

2024 — aujourd'hui

Applications web pilotées par l'IA et technologies web. Modèles et agents, tournés vers l'écran avec la même discipline.

La transition est moins tranchée qu'elle n'y paraît. Une application web moderne, ce sont des problèmes de systèmes distribués en miniature : gestion d'état, cohérence, reprise sur erreur, observabilité. Les noms changent, les questions restent.

La couche IA, elle, récompense les habitudes d'infrastructure d'une manière inattendue. Un modèle de langue est un composant incertain : il peut rendre des sorties différentes pour la même entrée, il peut se tromper en silence, et il échoue sans produire de message d'erreur. C'est exactement la classe de pannes travaillée pendant des années — seule la couche a changé.

Les questions que je pose en écrivant un agent sont donc les mêmes qu'en montant un serveur : Où est-ce que je mesure ? Comment saurai-je qu'il a mal répondu ? Jusqu'où puis-je revenir en arrière s'il casse ?

La différence s'aiguise sur un point. Quand un serveur casse, il vous le dit : le service tombe, la supervision alerte, une ligne atterrit dans un journal. Quand un modèle de langue casse, il produit une phrase fluide. La panne est silencieuse et, de surcroît, convaincante.

La conséquence pratique est que la supervision classique ne suffit pas. Pour un serveur, « est-il en ligne » suffit ; pour un modèle, il faut poser « est-ce juste » à part, et cette question ne se répond pas d'elle-même. Lier la sortie à un socle vérifiable — une source, un calcul, une mesure — doit faire partie de l'architecture.

Vingt ans d'habitude s'ajustent exactement ici : ne faites pas confiance à la sortie mais à son fondement.

Ce qui a été emporté

Le dénominateur commun des quatre périodes tient en quatre habitudes :

Toutes les quatre font aujourd'hui le même travail. La suite de vérification de ce site — la série de tests qui refuse de regarder des captures d'écran et lit la luminance sur le canvas — est un produit direct de la deuxième. Les procès-verbaux de décision du dépôt sont ceux de la quatrième.

Le fil commun : un budget d'erreur

Un concept revient dans les quatre périodes, même si son nom change à chaque fois.

En infrastructure, on l'appelait « objectif de disponibilité ». Cent pour cent de disponibilité n'existe pas ; ce qui existe, c'est de dire à l'avance combien d'interruption vous acceptez. Une équipe qui ne le dit pas rejoue la même discussion à chaque panne.

En réseau, cela s'appelait « latence acceptable ». En sécurité, « risque accepté ». En gestion des identités, « quelles exceptions sont approuvées ». Côté produit, « budget de performance ».

Tout cela désigne la même chose : écrire une limite à l'avance. Là où aucune limite n'est écrite, chaque décision devient une négociation, et les négociations sont en général gagnées par celui qui parle le plus fort sur le moment.

La section d'écriture de ce site a aussi un budget écrit : plus grand rendu de contenu sous 2,5 secondes, script de page sous 60 Ko, aucune porte d'opacité devant le texte. Les trois sont mesurés par la suite de vérification à chaque exécution. Le nombre dépassé, le test passe au rouge — aucune discussion ne s'ouvre.

C'est peut-être la leçon la plus pratique de vingt ans : la bonne volonté n'est pas un mécanisme de contrôle. Une limite est soit mesurée, soit inexistante.

Ce qui est resté derrière

Il y a des choses qui n'ont pas été emportées, et les lâcher fut plus dur que de les porter.

L'attente d'un fonctionnement sans faute. En infrastructure, l'objectif est zéro interruption. Côté produit, un objectif de zéro défaut aboutit à ne jamais rien livrer. Le nouveau critère n'est plus « est-ce que cela ne casse jamais » mais « que se passe-t-il quand cela casse ».

La résistance au changement. En salle serveur, le geste le plus sûr est de ne pas bouger ; toucher à un système qui marche est un risque. Côté produit, l'inverse vaut : ce qu'on ne touche pas vieillit. La même prudence doit s'appliquer dans une autre direction — non pas empêcher le geste, mais le rendre réversible.

Tenir l'invisibilité pour une vertu. Pendant vingt ans, le bon travail fut le travail qu'on ne remarque pas. Ce critère était juste dans son domaine mais ne se généralise pas. Là où il existe un champ dans lequel le travail doit être visible, le silence n'y est pas une vertu mais une absence.

Ce site est le procès-verbal de cette différence. Vingt ans durant j'ai bâti des systèmes que personne ne voit ; maintenant je bâtis la surface — et j'apprends que la surface aussi doit être mesurable.

Pourquoi la transition paraît facile et ne l'est pas

La plupart de ceux qui passent de l'infrastructure au produit tombent dans le même piège : ils supposent que la compétence technique est transférable. Elle l'est — mais seule, elle ne suffit pas.

Ce qui manque n'est pas technique. En infrastructure, « juste » est généralement singulier : une configuration marche ou ne marche pas, une sauvegarde restaure ou ne restaure pas. Côté produit, le juste est pluriel et dépend du contexte. Qu'une décision d'interface soit « juste » change selon pour qui elle est et ce qu'elle doit accomplir.

Pour une habitude d'ingénieur, c'est un état inconfortable. La certitude à laquelle on est habitué a disparu. À sa place vient la mesure : là où la vérité n'est pas singulière, mesurer ce que produit chaque option reste la seule voie honnête.

Le deuxième manque : le travail invisible n'a pas de public, le travail visible en a un. Pendant vingt ans, l'interlocuteur du travail était un système. Maintenant l'interlocuteur est une personne, et sa patience, son attention et son contexte varient. Ce n'est pas un problème à résoudre mais une réalité à prendre en compte.

Une note

Chacune des périodes ci-dessus contient des événements concrets qu'on pourrait raconter un à un : une migration précise, une nuit de panne précise, une décision d'architecture précise. Ce texte ne les contient pas.

La raison est simple : ce texte porte sur des disciplines, pas sur des cas. Les cas méritent des textes à eux, et chacun devrait arriver avec sa propre mesure — comme les autres écrits de cette section.

Il y a un risque à généraliser et j'en ai conscience : réduire vingt ans à quatre points aplatit les décisions réelles prises pendant ces années. Expliquer d'où vient une habitude n'est pas la même chose qu'expliquer comment on l'a acquise. La seconde prend plus de temps et exige des exemples plus concrets.

Cette liste a pourtant une fonction : elle fixe le terrain sur lequel vous lirez le texte suivant. Pourquoi une section d'écriture à ce point liée à la mesure a été bâtie ainsi s'explique par ces quatre habitudes. Le reste est dans les cas.