Comment faire du logiciel

L’agile, vingt-cinq ans après

En 2001, dix-sept personnes ont écrit une page. Sa première ligne plaçait les individus et leurs interactions au-dessus des processus et des outils. Un quart de siècle plus tard, toute une industrie vend des processus et des outils au nom de cette page.

Seize heures de formation font un Scrum Master. Le titre ne décrit rien de vérifiable. Il vient avec un calendrier d’événements, une garde-robe de casquettes et un vocabulaire qui impressionne ceux qui n’ont jamais rien livré. On cite le manifeste parce que le citer donne l’air intelligent. Presque personne n’applique ce qu’il dit, et personne ne mesure son propre échec.

Le vrai produit de tout ça, c’est la responsabilité diffuse. Le processus est suivi, les tableaux sont à jour, la vélocité est stable, et le logiciel est lent, en retard ou cassé. Personne ne répond. L’échec appartient à la méthode, ou à la façon de l’appliquer, et le remède, c’est davantage de méthode.

Quand tout le monde suit le processus, personne ne répond.

Ses propres auteurs l’ont dit. En 2014, Dave Thomas écrivait que le mot avait été « subverted to the point where it is effectively meaningless ». En 2018, Ron Jeffries disait aux développeurs de l’abandonner, et Martin Fowler nommait l’Agile Industrial Complex. Jeffries encore, sur les story points : « I may have invented story points, and if I did, I’m sorry now. »

Regardez plutôt ce qui sort. SQLite porte 590 fois plus de code de test que de code. Linux livre une version majeure tous les deux ou trois mois. Basecamp travaille par cycles de six semaines de sa propre invention et a jeté le backlog. Une huitaine de personnes autour de Jonathan Blow ont terminé The Witness. OpenCode a passé les 22 000 commits au grand jour. Ajoutez-y presque tout le logiciel open source sur lequel repose votre entreprise. Aucune de ces personnes ne s’est fait un nom comme gourou de l’agile. Dans chaque cas, quelqu’un répond de la direction, et le travail se juge à ce qui sort.

L’agile n’a rien d’une expérience marginale. Dans l’enquête de l’industrie elle-même, 71 % des répondants l’utilisent dans leur cycle logiciel, 63 % d’entre eux font du Scrum, et 11 % sont très satisfaits. C’est la norme, donc les résultats sont les siens. Un Apple IIe de 1983 répond à une frappe en 30 millisecondes ; un PC de 2014 avec des centaines de milliers de fois plus de transistors en met 50. Une revue parue dans Science en 2020 a multiplié deux matrices en Python ordinaire : 7 heures, 0,0006 % de ce que la machine pouvait faire. Le seul choix du langage donnait un facteur 47, et un code travaillé pour le matériel finissait en 0,41 seconde, plus de 60 000 fois plus vite. Casey Muratori a mesuré un facteur 10 ou plus entre le « clean code » et du code simple sur un problème élémentaire. Les ordinateurs ont gagné en vitesse, le mauvais logiciel a dépensé le gain, et il y a peu d’usages nouveaux à montrer en échange. La page web mobile médiane est passée de 505 Ko en 2014 à 2 559 Ko en 2025. En 2022, le CISQ chiffrait le coût de la mauvaise qualité logicielle à 2 410 milliards de dollars pour les seuls États-Unis. En juillet 2024, une seule mise à jour défectueuse a planté environ 8,5 millions de machines Windows.

Le logiciel est bogué et peu fiable, le web plus que tout, et la plupart des équipes sont dans le déni. Deux choses nourrissent ça. Les équipes sortent des outils plus compliqués que leur problème, qu’elles ne savent pas faire tourner de façon fiable. Et la compétence s’est raréfiée : Jonathan Blow avertit que le savoir-faire se perd, et David Graeber a donné leur nom aux cocheurs de cases et aux contremaîtres. L’agile leur a donné un calendrier.

L’agile produit rarement quelque chose de bon, et quand il en sort quelque chose de bon, c’est malgré l’agile. Ce sont des individus avec de l’envie et de l’ambition qui l’ont fait, pas des comités là pour toucher leur salaire, avoir l’air occupés et rester entre les garde-fous. Les transformers ne sont pas sortis d’un sprint planning. La transe dure depuis vingt-cinq ans. Elle peut s’arrêter.

Il y a de bonnes idées dans l’agile : les petits incréments, l’intégration continue, le retour rapide, un backlog ordonné. C’est de l’ingénierie, elles restent. Le reste s’en va : les rituels, les casquettes, les sprints, les points. Une équipe doit reposer sur ce qui se vérifie. Un fichier dans un dépôt, une barrière dans un pipeline, un chiffre sur une courbe.

Sources Manifeste pour le développement Agile de logiciels · The Scrum Guide · Scrum Alliance, Certified ScrumMaster · Thomas, Time to Kill Agile · Jeffries, Developers Should Abandon Agile · Jeffries, Story Points Revisited · Fowler, The State of Agile Software in 2018 · How SQLite Is Tested · How the Linux development process works · Shape Up, Bets, Not Backlogs · The Witness · OpenCode · 17th State of Agile Report · Luu, Computer latency: 1977-2017 · Leiserson et al., There’s plenty of room at the Top, Science, 2020 · Muratori, Clean Code, Horrible Performance · CISQ, The Cost of Poor Software Quality in the US · 2024 CrowdStrike outage · Web Almanac 2025, Page Weight · Blow, Preventing the Collapse of Civilization · Graeber, Bullshit Jobs

La bonne foi

Tout ceci suppose des gens qui veulent que le produit soit bon. Si vous êtes entouré de gens qui ne veulent rien faire, aucune méthodologie ne vous sauvera, celle-ci comprise. Vous avez un problème plus grave, et il passe en premier.

Ça suppose aussi des gens qui connaissent leur métier. Les chiffres éclairent un jugement et ne le remplacent jamais. Aucun processus n’apprend à quelqu’un ce qu’est du bon travail.

L’essentiel de la machinerie managériale repose sur l’hypothèse inverse. McGregor la décrivait en 1960 : les gens détestent le travail et il faut les surveiller pour qu’ils le fassent. Feuilles de temps, comptes rendus quotidiens et burndown charts sont cette hypothèse avec une interface moderne. Voir les gens comme des unités économiques dont il faut extraire de la valeur est ridicule, et ça produit le comportement que ça redoute.

Une méthode qui oblige les gens à prouver qu’ils travaillent suppose qu’ils ne le feraient pas autrement. Recrutez des gens qui le feraient, et la méthode n’a presque plus rien à faire.

Sources McGregor, Theory X and Theory Y (The Human Side of Enterprise, 1960) · Principes du Manifeste agile : « Build projects around motivated individuals… and trust them to get the job done. »

Pas de cérémonie

Une cérémonie, c’est une réunion à laquelle on va parce qu’il est l’heure. Le mot est honnête : il décrit une croyance, et un dogme à observer. Personne n’a besoin de la foi pour travailler. Une personne libre et intelligente sait quand il faut faire quelque chose, le fait, et sollicite qui elle a besoin au moment où elle en a besoin.

Personne n’a besoin d’un rituel pour savoir quand travailler.

• Une réunion est une invitation. Un sujet, les gens concernés, un résultat écrit après coup. Ils acceptent ou ils déclinent. Personne ne vient pour faire semblant.
• L’écrit d’abord. Un état d’avancement se lit dans le dépôt et dans l’outil de suivi. Une décision s’écrit là où elle s’applique. Le temps passé ensemble sert à ce que l’écrit ne sait pas faire : débattre, concevoir, débloquer.
• N’importe qui peut demander l’aide de n’importe qui. Sans créneau, sans intermédiaire.
• La rétrospective est continue. Celui qui voit quelque chose à améliorer le met au backlog, le porte, et monte sa priorité en écrivant pourquoi. Personne n’arrête toute l’équipe tous les quinze jours pour ramasser des post-it, et personne ne demande la permission.
• La concentration se protège. Le logiciel se fait dans de longues plages de réflexion sans interruption. Une réunion au milieu de l’après-midi coûte tout l’après-midi.

Chacun est un acteur productif qui a son mot à dire. Une armée marche aux ordres. Une équipe d’ingénieurs marche avec des gens qui voient ce qu’il y a à faire.

Sources The Scrum Guide : les événements d’un sprint · Graham, Maker’s Schedule, Manager’s Schedule

Un changement, un auteur

Chaque changement a un auteur, et l’auteur en répond, jusqu’en production et après. Quand une livraison dégrade quelque chose, celui qui a fait le changement comprend pourquoi et corrige. C’est lui qui a le contexte. La responsabilité, ici, c’est ça, et ça n’a rien à voir avec le blâme.

Trouver un coupable ne sert à rien, et ça apprend aux gens à cacher les problèmes. Le but est de corriger, de comprendre, et de rendre la panne impossible la prochaine fois : un test, une barrière, un déploiement plus sûr, une meilleure mesure, une alerte qui aurait sonné. Le post-mortem est un fichier commité dans le dépôt concerné, avec une chronologie, les causes et les actions, chaque action avec son numéro de tâche.

La responsabilité exige le pouvoir qui va avec. Celui qui répond d’un changement peut lire les logs, atteindre la production par le chemin normal, revenir en arrière et décider. Tenir les gens pour responsables de ce qu’ils ne peuvent pas toucher, c’est retomber dans le théâtre.

Un auteur. Une réponse. Pas de coupable.

Sources Google SRE, Postmortem Culture: Learning from Failure

Des rôles aux noms simples

Scrum Master, Product Owner, Agile Coach, Release Train Engineer : des casquettes qu’il faut une formation pour comprendre. Un rôle demande un mot simple et une phrase sur ce dont il répond.

Tout ceci vise les équipes de taille moyenne à grande. Une équipe plus petite cumule plusieurs rôles sur une personne, une plus grande donne à chaque rôle ses propres gens, et ce dont chaque rôle répond ne change pas. Un duo n’a besoin de rien de tout ça.

Chacun est autonome dans sa façon de travailler. Un développeur qui monte une priorité en écrivant pourquoi l’emporte sur l’ordre du backlog. Le cap appartient au capitaine : il écoute, il décide, et il répond de la direction.

Si on ne peut pas dire de quoi quelqu’un répond, le rôle n’existe pas.

Sources The Scrum Guide · WCAG 2.2

Un tech lead qui sait dire non

Les mauvaises décisions techniques survivent parce que personne n’est en position de les arrêter. Un tech lead fort, c’est quelqu’un qui peut dire : non, là on fait n’importe quoi. Ça ne retire aucune responsabilité aux autres développeurs. Ça ouvre un échange technique pointu, preuves sur la table : un benchmark, un prototype, un mode de panne, une référence. Personne dans cet échange n’a peur de casser des choses.

Trop de projets se trimballent un système que leurs prédécesseurs ont laissé insuffisant, ou simplement pas fini. Un framework maison, une migration à moitié faite, deux façons de tout faire. Par flemme ou par fausse urgence, tout le monde accepte de le porter encore un peu. C’est un boulet à la cheville, et les intérêts se paient à chaque changement. Supprimer du code est un travail qui a de la valeur. Finir une migration avant d’en commencer une autre est une règle.

Quand les chiffres parlent, la décision est simple.

• Plusieurs développeurs se plaignent de la même chose ? Ce n’est plus un sujet de discussion. Ils travaillent sur le produit à plein temps, ils ont leur mot à dire, et ils sont autonomes : s’il y a un truc à faire, ils le font et ils l’intègrent.
• Un vrai désaccord se tranche en mesurant. Écrivez l’expérience, lancez-la, gardez le résultat dans le dépôt. L’ancienneté et le volume sonore ne sont pas des arguments.
• Préférez le choix ennuyeux. Chaque nouvelle technologie coûte de l’attention toute sa vie. Une équipe peut s’en offrir très peu, alors réservez-les à ce qui rend le produit différent.
• Les décisions réversibles se prennent vite. Les irréversibles, une API publique, un modèle de données, un fournisseur, méritent le temps et l’écrit qui vont avec. Dès que des gens dépendent d’un comportement, il fait partie du contrat, documenté ou non.

Sources Fowler, Technical Debt · McKinley, Choose Boring Technology · Hyrum’s Law

La guerre à Conway

« Toute organisation qui conçoit un système produira une conception dont la structure est une copie de la structure de communication de l’organisation. »Melvin Conway, 1968

Cette loi prend le dessus en silence. On découpe les équipes pour des raisons de budget ou de hiérarchie, et deux ans plus tard le logiciel a les mêmes coutures, les mêmes murs et la même file d’attente à chaque frontière. Une équipe front et une équipe back donnent une API en forme de réunion. Trois prestataires donnent trois systèmes et un job de synchronisation qui n’appartient à personne. Personne ne l’a décidé. Tout le monde le subit.

On ne peut pas l’abroger. On peut la rendre consciente. Chaque découpage organisationnel a une conséquence sur le logiciel, et cette conséquence se lit à l’avance : si on sépare ces deux équipes, on ne changera plus jamais ceci sans cela, et on sait qu’on en aura besoin. Dite à voix haute, la phrase change la décision. On prend l’autre découpage, ou on s’arrange autrement. Utilisée à dessein, la loi travaille pour vous : dessinez les équipes autour de l’architecture que vous voulez. Thoughtworks appelle ça la manœuvre de Conway inverse.

Dessiner les équipes, c’est dessiner le système.

• Gardez proche ce qui change ensemble. Un dépôt ou plusieurs, personne n’est obligé d’adopter un monorepo. C’est la distance entre ce qui bouge d’un seul bloc qui coûte.
• Une équipe possède une tranche entière du produit, de la donnée à l’écran, et peut la livrer sans rien demander à une autre équipe. Un changement qui demande trois équipes est un défaut de conception.
• Pas d’équipes isolées autour d’un travail interdépendant. Chaque modification devient une chaîne interminable de communications lentes, le run devient une corvée et tout se traîne. Y ajouter des gens aggrave les choses : les chemins de communication croissent plus vite que l’effectif.
• Pensez en domaines. Nommez les choses comme le métier les nomme. Tracez les frontières autour du sens, pas des couches techniques. Des modules à l’échelle d’un monolithe modulaire conviennent à la plupart des produits bien avant les microservices.

Sources Conway’s Law et l’article de 1968 · Fowler, Conway’s Law · Thoughtworks, Inverse Conway Maneuver · Team Topologies · Brooks’s law · Fowler, Domain-Driven Design · Fowler, Monolith First

Rien ne vit dans une seule tête

Le savoir appartient au dépôt, aux tests et à l’habitude de relire le travail des autres.

• Un nouveau livre dès ses premiers jours. Le README, l’installation en une commande et CODEOWNERS suffisent pour démarrer. Chaque question qu’il a dû poser à voix haute est un bug de la documentation, et c’est lui qui le corrige.
• La relecture diffuse le savoir autant qu’elle attrape des bugs. Un petit changement reçoit une vraie relecture. Une pull request de deux mille lignes reçoit un pouce levé.
• Un débutant fait des erreurs. Donnez-lui du travail à l’échelle de ce qu’il sait faire, puis un peu plus. Ça s’appelle du mentorat, et une équipe qui n’en est pas capable n’est pas capable de grand-chose.
• La compétence est une pratique quotidienne. Lire les sources de ses dépendances, les standards, les post-mortems des autres. Le temps pour ça fait partie du travail.
• Recrutez sur le travail. Faites lire du vrai code, trouver un vrai bug, écrire une vraie spécification. Un quiz mesure un quiz.

Un système qu’une seule personne comprend est un incident qui attend ses vacances.

Sources Google Engineering Practices, Small CLs

Une seule source de vérité

Le code d’abord. Ce que contient le dépôt est vrai. Un ticket, une page de wiki, un tableau de bord ou une diapo qui dit autre chose a tort.

Générez tout ce qui peut l’être : les références d’API depuis les schémas, les schémas depuis les types ou l’inverse, les diagrammes depuis du texte, l’infrastructure depuis du code, les changelogs depuis les commits ou des fragments, les bibliothèques clientes depuis les contrats. Réécrire à la main la même vérité à un second endroit, c’est de la double maintenance, et la double maintenance finit en ambiguïté dans le système. La CI vérifie que ce qui est généré est à jour.

Quand ils divergent, le dépôt gagne.

Ce qui ne se génère pas, c’est le pourquoi. Pourquoi cette base, pourquoi pas cette bibliothèque, ce qui a été essayé et a échoué. Ça s’écrit à la main, court, dans le dépôt, à côté de ce que ça concerne : un enregistrement de décision, ou src/md. C’est encore plus vrai à l’ère de l’IA, parce que l’intention vit désormais dans des prompts, et qu’un prompt s’évapore. Gardez ce qu’un prompt a décidé en Markdown dans src/md, et pointez-y depuis le commit. Laissez la transcription brute de côté.

Les documents vivent dans docs/, à côté du code : techniques, fonctionnels, d’architecture, d’exploitation. Ils changent dans le même commit que ce qu’ils décrivent, et ils passent en relecture. Arrêtez de les faire mariner dans des outils externes à deux balles. Les formats ouverts, Markdown, Mermaid, texte brut, SVG, CSV, couvrent presque tous les besoins. Ils sont gratuits, ils se comparent, ils s’exportent partout, ils survivent aux éditeurs, et les machines les lisent aussi bien que les gens. Des fortunes partent dans des outils qui ralentissent les équipes.

Les outils restent légers. Chacun fait un travail, a une ligne de commande ou une API, et se remplace. N’adoptez jamais un outil où tout doit passer par un tableau de bord visuel : ce qui exige une souris ne se scripte pas, ne se relit pas et ne se versionne pas.

Le rangement n’est pas une manie. L’utilisateur ne voit que le produit fini, mais le produit est une sortie du dépôt : de son code et de la façon dont il est organisé. Un dépôt mal rangé est une mauvaise entrée. Gardez l’organisation ennuyeuse que tout le monde reconnaît.

projet/
  README.md         ce que c'est, comment le lancer
  CONTRIBUTING.md   comment le modifier
  CHANGELOG.md      ce qui a changé, pour les humains
  SECURITY.md       comment signaler une faille
  THREAT_MODEL.md   ce qu'on défend, et contre quoi
  LICENSE           ce qu'on a le droit d'en faire
  CODEOWNERS        à qui s'adresser
  .editorconfig     le formatage, réglé
  .gitattributes    les fins de ligne, réglées
  src/
    md/             l'intention, à côté du code
  docs/             technique, fonctionnel, architecture, runbooks
  tests/
  fixtures/         données de test, petites et versionnées
  scripts/          les tâches en une commande
  deploy/           infrastructure en code
  containers/       comment c'est empaqueté
  .github/          ou l'équivalent de votre hébergeur : la CI, en code

Sources src/md · Docs as code, Write the Docs · Diátaxis · The C4 model · Nygard, Documenting Architecture Decisions et ADR · Mermaid

Les standards d’abord

La plupart de ces décisions ont été prises il y a longtemps, par tout le monde. On a déjà la réponse. On le fait, point, et on passe à autre chose. Gardez vos débats pour vos vrais problèmes. Une décision coûteuse prise alors que la bonne manière était à une recherche web de distance n’a aucune excuse, et plus elle est tranchée tôt, moins elle coûte.

Ne transformez jamais en débat ce que le monde a déjà approuvé.

Ça demande de la rigueur : connaître les standards, les avoir assimilés, les maintenir. La compétence se voit à ce qu’il a fallu inventer de peu dans un projet.

Sources chaque ligne ci-dessus renvoie à son standard

Chaque action a un numéro

Chaque action reçoit un numéro de tâche et entre au backlog. Même ponctuelle. Même un correctif en production à trois heures du matin. Même un changement de réglage sur un serveur. C’est la seule bureaucratie à sacraliser, parce qu’elle coûte une ligne et qu’elle répond, des années plus tard, à la seule question qui compte sur un changement : pourquoi.

fix(api): cap the retries (PROJ-142)

Pas de numéro, pas de commit.

La chaîne va de la demande à la production : tâche, commit, relecture, build, livraison, déploiement. D’une ligne de code on remonte à la raison, d’un rapport de bug on remonte au code. La CI refuse le commit sans numéro.

L’outil de tickets, lui, importe peu, et le choix mérite une heure. N’importe lequel fait l’affaire s’il a une API ou une ligne de commande, des numéros courts jamais réutilisés, et un export en fichiers simples. Le commit survit à l’outil. Le backlog est une liste ordonnée, et l’ordre est la seule chose qui y demande du jugement.

Sources Conventional Commits 1.0.0

Une seule commande

Cloner, une commande, ça tourne. Tester : une commande. Construire, livrer, réinitialiser la base locale : une commande chacun, la même sur toutes les machines, et la même que celle de la CI. Ce que fait la CI et ce que fait un développeur ne doivent jamais être deux choses différentes.

• L’environnement est du code. Figez la chaîne d’outils et les dépendances système : un dev container, Nix, un fichier de version, ce qui convient.
• Gardez les environnements semblables. Mêmes services, mêmes versions, même chemin de déploiement, du portable à la production. Chaque écart est un endroit où les bugs se cachent.
• La configuration vit hors du build. Un seul artefact traverse tous les environnements. Ce qui change, c’est la configuration, déclarée et validée au démarrage.
• Les secrets n’entrent jamais en clair dans l’historique. Chiffrés dans le dépôt ou tenus dans un coffre, renouvelés, recherchés à chaque commit. Une fois commité, un secret a fui.

Si ça ne marche que sur votre machine, c’est le dépôt qui est cassé.

Sources Twelve-Factor, Config et Dev/prod parity · Dev Containers · Nix · SOPS · Gitleaks

Les tests sont la spécification

Une spécification que personne n’exécute s’éloigne du produit dès le premier jour. Les tests en sont la version qui ne peut pas mentir. Les exemples de l’expert métier deviennent exécutables, et une exigence est faite quand son test passe.

• Beaucoup de tests rapides, peu de lents. L’essentiel au niveau de l’unité, moins entre composants, une poignée de bout en bout. Toute la suite tourne à chaque changement.
• Un bug reçoit un test avant son correctif. Il échoue, puis il passe, et ce bug est parti pour de bon.
• Traitez un test instable comme un incident de production. Mettez-le en quarantaine, donnez-lui un numéro, corrigez-le. Une suite que les gens ont appris à relancer ne protège plus rien.
• Testez les frontières. Les contrats entre services, les migrations sur des données réalistes, le comportement sous charge, la reprise après panne.
• La couverture montre ce que rien ne vérifie. Courir après le pourcentage produit des tests qui ne vérifient rien.

Si personne n’exécute la spécification, elle dérive.

Sources Vocke, The Practical Test Pyramid · Fowler, Eradicating Non-Determinism in Tests · Pact : tests de contrat

Reconstruire, octet pour octet

Une entreprise sérieuse sait reconstruire n’importe quelle version de son application, à n’importe quel point de son histoire, à l’identique, octet pour octet. Un client signale un bug dans une version vieille de dix-huit mois : vous reproduisez ce binaire exact, depuis les sources, et vous le regardez. Un auditeur demande ce qui tournait en production tel jour : vous pouvez le montrer.

Ce qu’on ne sait pas reconstruire, on ne peut pas en répondre.

Un build est reproductible quand, avec le même code source, le même environnement de build et les mêmes instructions, n’importe qui peut recréer des copies identiques bit à bit des artefacts. La comparaison se fait avant la signature, qui change les octets. C’est aussi une propriété de sécurité. En mars 2024, une porte dérobée a été découverte dans xz, une bibliothèque de compression répandue sur Linux. Le fichier modifié n’était pas dans le dépôt Git : il n’existait que dans les archives publiées. Ce qui est publié doit venir du dépôt, et pouvoir être comparé à lui.

• Tout figer. La chaîne d’outils, chaque dépendance dans un fichier de verrouillage avec son empreinte, les images de base par empreinte.
• Garder ses propres copies. Un registre qui disparaît ne doit pas rendre votre historique inconstructible.
• Retirer ce qui change tout seul. L’horloge, l’ordre des fichiers, le chemin du build, la machine, la locale.
• Le vérifier. Construire deux fois dans des environnements propres et comparer les empreintes. La CI refuse une livraison dont les deux builds diffèrent.

Un projet open source personnel, c’est une autre histoire.

Sources Reproducible Builds, definition · Reproducible Builds · XZ Utils backdoor

Livrer la preuve

Une livraison, ce n’est pas qu’un binaire. À côté de lui, à chaque fois, aussi vitaux que l’application elle-même :

• Le changelog : ce qui a changé, pour les humains.
• La nomenclature logicielle (SBOM) : chaque composant et sa version dans le build, dans un format ouvert. Quand Log4Shell est sorti en 2021, des entreprises ont passé des jours à chercher si elles utilisaient seulement Log4j. Avec une nomenclature, « sommes-nous concernés ? » est une requête.
• La provenance : quel commit, quel constructeur, quelles entrées.
• La signature : pas une obligation, un gage de qualité et de sécurité. Qui a publié ça, et la preuve que rien n’a changé depuis. Les clés vivent hors du dépôt, et un client vérifie avant d’installer.
• Les licences : ce que vous livrez, et à quelles conditions.

Livrez la preuve à côté du produit.

Sources SPDX et CycloneDX · SLSA · Sigstore · OpenSSF Scorecard · Log4Shell

Savoir ce qu’on défend

Un scan de dépendances couvre une porte. La sécurité commence par quatre questions simples, avec des réponses écrites : sur quoi travaille-t-on, qu’est-ce qui peut mal tourner, qu’allons-nous faire, en a-t-on fait assez. Les réponses tiennent dans un THREAT_MODEL.md à la racine du dépôt, mis à jour dans le même commit que ce qui les change.

• Le moindre privilège. Chaque personne, service et job de CI a les droits dont il a besoin et rien de plus. Aucun job de build ne détient les clés de la production.
• Des identifiants à courte durée, pas de comptes partagés. Les jetons expirent. Tout ce qui peut atteindre la production exige une authentification forte.
• Ne faites confiance à rien à la frontière. Validez les entrées, encodez les sorties, utilisez les protections du framework. Le standard de vérification de l’OWASP est une liste de contrôle toute prête.
• Laissez une trace. Qui a fait quoi en production, et quand, hors de portée des gens que ça enregistre.
• Répétez la fuite. Comment renouveler tous les secrets, et en combien de temps ? C’est aussi un chiffre.
• Laissez la porte ouverte à qui trouve une faille. SECURITY.md, security.txt, et une réponse.

Écrivez ce que vous défendez, et contre quoi.

Sources Threat Modeling Manifesto · OWASP Threat Modeling Cheat Sheet · STRIDE · OWASP ASVS · NIST SSDF · Principle of least privilege

Toujours livrable

Plus de Kanban, moins de sprint. Le travail coule. Il n’arrive pas par caisses de deux semaines. Le tronc peut partir en production à tout moment, et la vitesse de la boucle entre une idée et sa vérification est l’un des chiffres les plus importants d’une équipe.

À tout moment : déployer, tester, mettre à jour.

• Développement sur tronc. Un tronc, des tags, des branches de fonctionnalité qui vivent quelques heures ou quelques jours, des branches de correctif. Une branche longue est une fusion qu’on a choisi de rendre plus difficile.
• Limitez le travail en cours. Le temps passé dans le système croît avec ce qu’il contient. Finir vaut mieux que commencer.
• Séparez déployer et publier. Le travail inachevé part éteint derrière un drapeau, et les drapeaux sont retirés quand ils ont servi.
• Déployez progressivement, et sachez revenir en arrière. Canari, bleu-vert, déploiement graduel, retour arrière automatique sur mauvais signal. En août 2012, une panne logicielle a envoyé sur le marché les ordres erronés de Knight Capital pendant environ 45 minutes et lui a coûté quelque 440 millions de dollars. Le déploiement est la chose la plus dangereuse que font la plupart des équipes : rendez-le ennuyeux.
• Donnez à chaque pull request son environnement quand vous pouvez vous le permettre : l’expert métier essaie le changement sur place et dit tout de suite si ça va dans la bonne direction. L’agile avait cette idée. Elle l’a juste mal définie.

Sources Trunk Based Development · Fowler, Continuous Integration · Little’s law · Feature Toggles et OpenFeature · Canary Release · Blue-Green Deployment · Knight Capital Group · Forsgren, Humble, Kim, Accelerate

Des barrières qui refusent

Sur les sujets qui ne se débattent pas, la conclusion est automatique. Les risques de sécurité montent chaque année, et être pointu et à jour sur ses dépendances passe en premier. Ici, la rigueur est presque dictatoriale, et elle appartient à la machine. Ce qui est automatisé n’a besoin ni de rappel, ni de réunion, ni de gendarme. La CI refuse :

• TraçabilitéUn commit sans numéro ou format valide. Une entrée de changelog manquante.
• ExactitudeUn test qui échoue, une erreur de type, des fichiers générés pas à jour.
• StyleCe que signalent le formateur et le linter.
• VulnérabilitésLes failles connues de gravité haute ou critique, dans les dépendances, les images et le code.
• FraîcheurUne dépendance en retard de plus de 90 jours. Les robots de mise à jour rendent ça peu coûteux.
• SecretsTout ce qui ressemble à un identifiant.
• LicencesUn composant que vous n’avez pas le droit de livrer.
• BudgetsUne régression de taille, de vitesse ou de mémoire au-delà de la limite convenue.
• ReproductibilitéUne livraison dont les deux builds diffèrent.

Dictatorial sur la barrière. Tenue par une machine, jamais par une personne.

Il y a toujours une issue de secours. En urgence, les administrateurs des outils font ce qu’ils veulent. La dérogation s’écrit : qui, pourquoi, un numéro de tâche, une tâche de rattrapage au backlog. L’urgence n’est pas une zone sans trace, et une dépendance sans rapport ne prend jamais un correctif urgent en otage.

Personne n’attend. Une IA relit chaque changement d’abord, instantanément, et un humain décide de fusionner. La relecture et les résultats automatiques suppriment les chemins critiques où les gens font la queue les uns derrière les autres. Les barrières elles-mêmes sont rapides, sinon on les contourne. Une CI lente reçoit un numéro de tâche comme n’importe quel bug.

Sources OWASP Top 10:2021, A06 · OSV · Renovate · Semgrep · Gitleaks · REUSE

Mesurer le système, jamais la personne

Chaque produit a des chiffres qui disent la vérité sur lui. Un service web a sa latence de queue, un jeu son temps d’image, une application de bureau son temps de démarrage et sa mémoire, un traitement par lots sa durée, une application mobile ses sessions sans plantage et sa batterie. Trouvez les vôtres. Partez de ce que ressent l’utilisateur, puis de ce que vit l’équipe, et mettez-les sur une courbe que tout le monde sait lire.

La queue de distribution mérite l’attention. Dans un système qui se déploie en éventail, un seul composant lent ralentit toute la requête : le cas rare pour un serveur devient le cas courant pour vos utilisateurs. Une moyenne cache exactement ça.

Jamais mesuré : les lignes de code. Le nombre de commits ou de pull requests. Les heures, les jours de présence. Les story points. Un classement des gens. Aucune métrique personnelle, aucune. Personne n’est là pour être comparé.

La seule chose qui compte, c’est la qualité du produit fini.

Sources DORA, the four keys · Forsgren, Humble, Kim, Accelerate · Dean, Barroso, The Tail at Scale · Web Vitals · Loi de Goodhart

Voir à l’intérieur

Logs, métriques et traces font partie du produit, écrits avec lui et relus avec lui. Quand quelque chose casse, la première question trouve sa réponse sur une courbe, pas au téléphone.

• Commencez par les quatre signaux d’or : latence, trafic, erreurs, saturation.
• Des logs structurés, une trace sur tout le chemin. Une requête a un identifiant du premier saut au dernier.
• Les alertes sont du code, dans le dépôt. Une alerte sonne sur ce que ressentent les utilisateurs, et quelqu’un peut agir dessus. Une alerte sur laquelle personne n’agit est supprimée.
• Chaque alerte renvoie à un runbook, dans docs/, et le runbook raccourcit à mesure que la correction s’automatise.
• Regardez aussi le produit : rapports de plantage, temps réels des utilisateurs, erreurs que personne ne signale.

Sans télémétrie, on devine.

Sources Google SRE, Monitoring Distributed Systems · OpenTelemetry

Des promesses en chiffres

« Il faut que ce soit rapide et fiable » ne veut rien dire. « 99,9 % des requêtes servies en moins de 300 ms sur trente jours » veut dire quelque chose, et tout le monde peut lire si c’est vrai. Écrivez l’objectif, dans le dépôt, avec le côté produit.

L’écart entre l’objectif et la perfection est un budget. Tant qu’il tient, livrez vite et prenez des risques. Quand il est dépensé, la fiabilité passe d’abord jusqu’à ce qu’il se reconstitue. L’éternelle dispute entre fonctionnalités et stabilité devient la lecture d’un chiffre. Il en va de même des budgets de poids de page, de mémoire, de temps de démarrage ou de coût : une limite convenue d’avance, tenue par une barrière.

Mettez un chiffre sur la promesse, ou ne la faites pas.

Sources Google SRE, Service Level Objectives · Google SRE, Error Budget Policy

Les données survivent au code

Le code se réécrit. Une donnée client perdue est perdue. En janvier 2017, pendant un incident chez GitLab, la recherche et l’utilisation des sauvegardes ont complètement échoué, et des données de production ont été perdues pour de bon.

• Restaurez à intervalles réguliers, automatiquement, et mesurez le temps que ça prend. Ce chiffre est votre vrai temps de reprise.
• Les migrations sont du code versionné, relu et testé sur un volume réaliste.
• Changez les schémas par étapes : étendre, migrer, contracter. L’ancienne et la nouvelle version de l’application tournent côte à côte pendant un déploiement.
• Sachez ce que vous détenez. Où vivent les données personnelles, pourquoi, combien de temps, et comment elles sont supprimées.

Une sauvegarde que personne n’a restaurée est un espoir.

Sources GitLab, Postmortem of database outage of January 31 · Evolutionary Database Design · Fowler, Parallel Change

Les dates viennent du passé

Les points de complexité et la vélocité sont des nombres abstraits inventés pour éviter de dire une durée, puis reconvertis en durée quand même. Les équipes se disputent entre un cinq et un huit, et le nombre ne prédit rien.

Sans expérience, une estimation ne veut rien dire. Avec, c’est un jugement : un objectif, jamais une garantie. Quand on vous demande « pour quand ? », regardez combien de temps un travail comparable a vraiment pris, et répondez par une fourchette. L’outil de suivi et les commits contiennent déjà les données.

Estimez à partir de ce qui s’est passé.

Les deadlines, très bien. Gardez-en une finale, pour que le périmètre s’y adapte, et des dates de livraison idéales en chemin. Puis mesurez l’écart entre la date idéale et la date réelle. Si vous êtes systématiquement en retard, ce sont vos attentes qui sont fausses. Réajustez-les. Quand une date est fixe, on coupe du périmètre. Couper dans la qualité ne fait que déplacer la facture.

Sources Reference class forecasting · Little’s law

Le coût est une mesure

L’argent est un chiffre comme les autres, et une équipe doit savoir le lire. Le prix d’une licence se voit. Le coût des heures qu’elle gaspille ne se voit pas, et il est en général plus élevé. On achète des outils pour rassurer des gens qui ne s’en serviront jamais, et chaque développeur en paie le prix tous les jours.

• Comptez l’attente. Dix minutes de CI, vingt développeurs, cinq changements par jour chacun, 220 jours travaillés : environ 3 700 heures par an, à peu près deux temps pleins à regarder une barre de progression.
• Comptez les réunions. Pour un sprint d’un mois, le Scrum Guide autorise jusqu’à huit heures de planification, quatre de revue et trois de rétrospective, plus quinze minutes par jour. Ça fait environ vingt heures par personne et par mois, une heure sur huit. Une équipe de douze peut y passer 240 heures par mois avant d’écrire une ligne.
• Comptez un outil en entier. La licence, l’intégration, la formation, les heures qu’il gaspille, et ce que coûtera d’en partir. Le prix par siège grandit avec l’équipe. Les heures gaspillées aussi.
• Connaissez le coût de fonctionnement du produit, par utilisateur ou par requête, sur la même courbe que le reste. Chaque ressource a un propriétaire. Ce qui dort s’éteint.
• Préférez ce que vous pouvez quitter. Les formats ouverts et les interfaces standards empêchent un fournisseur de fixer votre prix. Chiffrez la sortie avant de signer.

Chiffrez les heures, pas la licence.

Sources FinOps Foundation · The Scrum Guide : les durées maximales

Le logiciel est vivant

Le code est un objet vivant, et ce qui vit se taille. Chaque fonctionnalité coûte quelque chose tant qu’elle existe : tests, support, surface d’attaque, attention. On célèbre ce qu’on ajoute, on planifie rarement ce qu’on retire, et les produits coulent sous leur propre poids.

• Sachez ce qui sert. Les chiffres disent quelles fonctionnalités personne n’ouvre.
• Le capitaine décide de ce qui part. Un retrait reçoit un numéro, comme n’importe quel changement.
• Retirez au grand jour. Annoncez, prévenez dans le produit, donnez une date, puis faites-le. Quelqu’un dépend de chaque comportement que vous livrez.
• Nettoyez ce que personne ne voit. Le code mort, les drapeaux périmés, les dépendances inutiles, les migrations finies.
• Remplacez progressivement. Faites pousser le nouveau système autour de l’ancien et passez morceau par morceau. Les grandes réécritures sont l’endroit où les projets vont mourir.

Ce qui ne sert pas s’en va.

Sources Fowler, Strangler Fig · Hyrum’s Law

Changer sans crainte

Les temps changent vite. Être réactif était la bonne idée de l’agile, et ça n’a jamais voulu dire mettre le bazar toutes les cinq secondes. Ça veut dire des plateformes, des outils et surtout des compétences qui permettent d’évoluer sans l’angoisse de tout casser. Petits changements, tests, barrières, builds reproductibles, retour arrière, observabilité : tout ce qui précède sert à ça. Une équipe qui a confiance dans son filet change les choses. Une équipe qui n’a pas confiance ne touche plus à rien, et le produit commence à mourir.

L’IA a sa place dans cette boîte à outils : pour écrire, relire, explorer, automatiser ce qui était trop fastidieux à automatiser. Ça reste facultatif, mais une équipe qui refuse de voir ce que les outils existants peuvent produire reste à la traîne. Ça ne change pas qui répond. Ce que produit un agent passe les mêmes barrières, avec le même auteur.

Un produit qui marche, et une équipe qui peut encore le changer l’an prochain.

Sources Manifeste pour le développement Agile de logiciels