Idée principale

On parle souvent des bonnes pratiques du logiciel comme d'un stock stable : il suffirait de les documenter, de les déposer dans le fichier de directives d'un assistant de développement, et de lui demander de les appliquer.

Leur histoire dit autre chose. Les design patterns classiques répondaient à un monde logiciel donné ; le cloud, les systèmes distribués, l'asynchrone, les microservices et les architectures événementielles en ont fait apparaître un autre, et il a fallu inventer l'idempotence, les retries, les circuit breakers, les sagas, l'observabilité, la résilience distribuée. Aucune de ces pratiques n'est sortie d'une relecture des précédentes : elles sont nées de systèmes réels, de pannes, de migrations difficiles, de contraintes d'exploitation et de compromis douloureux.

Pour inventer une bonne pratique, connaître les anciennes ne suffit donc pas. Il faut sentir pourquoi elles ne suffisent plus, ce qui suppose d'avoir été exposé à un terrain qui résiste — et de savoir distinguer le moment où un pattern est une réponse élégante de celui où il n'est qu'une complexité inutile.

Pourquoi c'est important

Cela sépare deux capacités qu'on confond dès qu'un outil sait réciter le catalogue : appliquer une pratique et en produire une nouvelle. Un assistant qui compare des solutions, repère des récurrences et documente des pratiques émergentes aide sur la première ; rien n'établit qu'il couvre la seconde avant que le terrain n'ait rendu le besoin lisible.

Cela chiffre aussi un coût invisible pour une équipe qui n'affronte plus directement l'exploitation : elle hérite des patterns existants et perd le mécanisme qui permettait d'en inventer d'autres — une perte qui ne se constate qu'à la génération technologique suivante.

Nuances et limites

Le terrain n'a pas à être vécu en première personne pour instruire : un post-mortem sérieux, une trace d'exploitation, l'incident public d'une autre entreprise transportent une partie de la résistance. Ce qu'ils transmettent à coup sûr, c'est le pattern déjà trouvé ; leur capacité à faire émerger le suivant reste à démontrer.

Et toute résistance ne produit pas de pratique : beaucoup d'incidents ne laissent qu'un correctif local, parce que personne n'a pris le temps d'en tirer une règle.

Questions ouvertes

• Qu'est-ce qui, dans une panne, fait qu'elle engendre une pratique réutilisable plutôt qu'un correctif oublié le mois suivant ?