Angle
Un bug limité, un endpoint simple, un script, un test standard, un refactor modeste : ces tâches ne faisaient pas qu'occuper les développeurs juniors d'une équipe, elles les fabriquaient — et ce sont exactement celles qu'un assistant de développement produit le mieux. L'accélération ne retire donc pas d'abord des postes, elle retire trois mécanismes par lesquels une équipe logicielle reproduisait sa propre compétence : le coût du code, qui imposait de comprendre avant d'avancer ; la petite taille du système, qui gardait l'erreur analysable donc formatrice ; la première marche, qui exposait un débutant à la résistance du réel sans mettre le produit en danger. Aucun des trois n'était une pratique décidée — c'étaient les effets secondaires d'une lenteur que personne n'a jamais eu de raison de défendre —, et c'est pourquoi rien ne les remplace tout seul quand elle tombe. Ce qui les remplace se décide et s'écrit : ne pas merger de code que personne ne sait expliquer, relier les tests au fonctionnel, tenir un catalogue de patterns autorisés, traiter une sortie ratée de l'assistant comme une directive manquante, et juger le système à ce qu'on saurait en reconstruire plutôt qu'à ce qu'il affiche à l'écran.
Synthèse
Le premier apport de ces notes prises ensemble est de séparer ce que la discussion courante confond : la dégradation du code et la dégradation de la compétence. La première est ancienne et l'assistant n'en change que le débit ; la seconde est nouvelle, et c'est elle qui n'a pas de remède connu.
Les trois mécanismes perdus ne sont pas trois exemples du même fait, ils forment une chaîne. Le coût du code produisait de la compréhension au moment de produire ; la taille modeste du système rendait l'erreur rapportable à une décision, donc exploitable après coup ; les tâches d'entrée fournissaient les occasions d'erreur elles-mêmes. Supprimez le premier, le système grossit plus vite que la boucle d'apprentissage et le deuxième tombe avec lui. Supprimez le troisième, il n'y a plus rien à analyser du tout. L'accélération frappe donc la chaîne aux trois maillons à la fois, et par le même geste.
S'y ajoute une pression qui n'est pas technique. Le temps d'apprentissage n'a pas changé de durée, mais tout ce qui l'entoure s'est accéléré : son prix relatif a bondi, et chaque arbitrage local privilégie désormais la voie rapide sans qu'aucune décision n'ait supprimé la formation. C'est ce qui rend la perte invisible — elle ne se constate nulle part, elle s'accumule.
La dernière pièce est prospective et elle déplace l'enjeu hors de l'équipe : les pratiques d'un métier ne se déduisent pas de la relecture des précédentes, elles naissent d'un terrain qui résiste. Idempotence, retries, circuit breakers, observabilité sont venus de pannes et de migrations subies, pas d'un catalogue relu. Une génération qui n'affronte plus directement la résistance hérite des patterns existants sans les moyens d'en inventer d'autres.
Reste ce que ces notes proposent en face, et qui a une cohérence : chaque contre-mesure réinstalle explicitement un des mécanismes tombés. La reconstructibilité rend vérifiable la compréhension que le coût du code garantissait au passage. Le refus de merger du code inexpliqué met un prix immédiat sur ce que la dette de compréhension ferait payer plus tard. Le catalogue de patterns rétablit la contrainte d'homogénéité que la lenteur imposait par simple fatigue de tout réinventer. L'analyse des sorties ratées transforme l'échec en apprentissage au lieu d'une correction jetable. Et la difficulté réintroduite volontairement — dojos sans assistant, revues où l'on explique le code soi-même — assume ce que les autres ne couvrent pas : une compétence dont l'usage quotidien n'a plus besoin s'éteint si rien ne la sollicite.
Tensions / contradictions
Ces notes ne s'accordent pas sur la fatalité de la perte. Celles qui décrivent la chaîne rompue supposent que l'apprentissage passait par la production ; celles qui nuancent rappellent qu'un assistant employé comme tuteur — expliquer, comparer, faire verbaliser, simuler une revue — enseigne une partie de ce que la première marche enseignait. Si cette substitution fonctionne vraiment, la chaîne n'est pas rompue, elle est déplacée. Rien ici ne permet de trancher, et l'écart porte sur la part de l'apprentissage qui exige d'avoir été responsable du résultat.
Deuxième désaccord, économique : l'accélération finance aussi ce qu'elle menace, puisque le temps gagné sur la production pourrait payer l'apprentissage. La thèse dit que ce temps se redistribue par défaut vers plus de production ; elle ne dit pas qu'il ne peut pas être affecté ailleurs.
Troisième point de friction, celui-là interne : la boucle courte que ces notes défendent a son propre défaut. Elle enseigne le geste local et n'expose jamais aux effets de système, qui n'apparaissent qu'à grande échelle et tard. Une équipe qui protégerait uniquement les petites erreurs analysables formerait des développeurs aveugles à ce qui casse vraiment en production.
Questions
- Lesquelles de ces contre-mesures produisent réellement de la compétence, et lesquelles n'en produisent que la trace documentaire ? Écrire une décision d'architecture et savoir la prendre ne sont pas la même chose.
- Quelle exposition indirecte à la résistance du terrain — post-mortem d'une panne qu'on n'a pas vécue, trace d'exploitation, incident public d'une autre entreprise — suffit à faire émerger un pattern nouveau, et laquelle ne transmet que le pattern déjà trouvé ?
- Comment une équipe reconnaît-elle qu'elle a franchi le seuil où plus personne ne sait expliquer le système qu'elle maintient, autrement qu'en attendant la panne qui le lui apprendra ?
- Dans une organisation qui recrute des profils déjà formés, à quel niveau — l'entreprise, le secteur, l'école — le coût de la première marche doit-il être porté, puisque aucun acteur ne peut recruter à l'extérieur de l'ensemble auquel il appartient ?