Ouvrez un dépôt six mois après la mise en production d’une fonctionnalité, et vous pourrez en reconstituer beaucoup. Vous pouvez retracer l’architecture, examiner le schéma, lire les tests et voir exactement quelles lignes ont changé.
Ce que vous ne pouvez généralement pas reconstituer, c’est la conversation qui a rendu ces lignes nécessaires.
Le code ne vous dira pas qu’une règle de validation existe parce qu’un client envoie des exports mal formés. Il n’expliquera pas qu’une politique de nouvelle tentative inhabituelle empêche les transactions en double dans un système en aval. Il ne montrera pas qu’une interface plus propre a été rejetée après un test d’accessibilité, ni qu’une frontière de service reflète une contrainte contractuelle plutôt qu’une préférence d’ingénierie.
Git excelle à préserver l’historique du code. Il ne préserve l’intention que lorsqu’une équipe prend soin de la consigner et de la relier à l’implémentation.
Cet écart a toujours fait partie de l’ingénierie logicielle. Les outils de codage par IA le rendent plus visible. Un système peut lire chaque fichier d’un dépôt, suivre chaque symbole et générer un correctif techniquement convaincant tout en résolvant le mauvais problème.
Le problème n’est pas que le code soit trompeur. Le code répond à une question plus étroite.
Cinq couches de vérité en ingénierie
La plupart des changements logiciels qui comptent reposent sur cinq couches distinctes de preuves.
- Intention — Quel résultat l’utilisateur, le client ou l’entreprise demande-t-il ? Cela peut se trouver dans une spécification, un ticket, une conversation avec le support ou une note de réunion.
- Contraintes — Qu’est-ce qui ne doit pas casser ? Les promesses de compatibilité, les frontières de sécurité, les réglementations, les contrats, les budgets et les délais se trouvent souvent en dehors du dépôt.
- Implémentation — Comment le système fonctionne-t-il aujourd’hui ? Le code, les tests, les schémas, les dépendances et la configuration de déploiement constituent cette couche.
- Preuves d’exécution — Que se passe-t-il dans le système réel ? Les logs, les traces, les métriques, les données de production et les rapports d’incident peuvent contredire des hypothèses qui paraissent raisonnables dans le code.
- Historique des décisions — Pourquoi l’approche actuelle a-t-elle été choisie ? Les pull requests, les discussions de conception, les alternatives rejetées et les incidents précédents contiennent la réponse.
Le dépôt est le plus solide sur la troisième couche. Il contient des éléments des autres, mais rarement assez pour les représenter complètement.
C’est important, car les défaillances logicielles apparaissent souvent aux frontières entre les couches. L’implémentation correspond à une spécification obsolète. Le correctif satisfait le ticket mais viole une contrainte opérationnelle. Les tests passent parce qu’ils encodent les hypothèses d’hier. Le code est cohérent en interne alors que les données de production suivent un schéma que personne n’a documenté.
Un correctif localement correct peut malgré tout être le mauvais changement.
Ce que le dépôt ne peut pas expliquer à lui seul
Prenons le cas d’un utilisateur qui modifie un document, puis recherche la phrase mise à jour, pour ne voir apparaître dans les résultats que l’ancienne version. « Faire en sorte que la recherche se mette à jour immédiatement » semble être une demande claire. Le dépôt révèle plusieurs points de départ possibles, mais il ne peut pas déterminer à lui seul la bonne correction.
| Question | Source probable |
|---|---|
| Quelle version du document fait autorité ? | Document source et historique des révisions |
| Où l’ancien texte subsiste-t-il ? | Journaux de synchronisation, sortie d’extraction, index de recherche ou cache |
| Que signifie « immédiatement » pour ce produit ? | Promesse produit ou objectif de service |
| Les autorisations du document ont-elles changé en même temps que son contenu ? | Autorisations source et historique d’audit |
| Le résultat obsolète est-il limité à un utilisateur, une source ou une région ? | Traces de requête et métriques de production |
Le code de recherche peut expliquer comment les résultats sont renvoyés. Il ne peut pas vous dire si le véritable défaut vient d’un délai de synchronisation, d’une extraction obsolète, d’une invalidation de cache, d’une propagation des autorisations ou d’une attente que le produit n’a jamais définie.
Cette distinction devient encore plus importante dans les systèmes matures. Un champ qui semble obsolète peut encore servir un client historique. Un service qui paraît faire doublon peut en réalité séparer des données soumises à des exigences d’autorisation différentes. Une vérification apparemment excessive peut être la seule trace, au niveau du code, d’un incident de production que l’équipe actuelle n’a jamais connu.
Supprimer de la complexité a de la valeur. Supprimer de l’histoire déguisée en complexité coûte cher.
Même avec plus de contexte, on peut encore se tromper
La solution évidente consiste à donner plus de matière à l’IA : l’ensemble du dépôt, tous les tickets, tous les documents, tous les messages et tous les journaux.
Cela donne de l’accès, pas de la compréhension.
Les sources peuvent être obsolètes, contradictoires, spéculatives ou rédigées pour des publics différents. Une séance de brainstorming ne devrait pas l’emporter sur une spécification approuvée. Une exigence vieille de six mois ne devrait pas annuler en silence la décision produit prise hier. Un journal de production devrait être rattaché à la version, à l’environnement et au chemin de code qui l’ont produit. Une demande client ne devrait pas être traitée comme une exigence universelle sans vérification de son périmètre.
Un système de contexte sérieux a donc besoin de plus que de la simple récupération d’information. Il lui faut un moyen de raisonner sur :
- Autorité : Quelle source est habilitée à définir l’exigence ?
- Récence : Quelle information est à jour, et qu’est-ce qui a été remplacé ?
- Provenance : D’où vient chaque affirmation, contrainte ou conclusion ?
- Relations : Quels ticket, version, client, jeu de données et chemin de code vont ensemble ?
- Autorisations : Quelles sources peuvent être utilisées pour cette tâche et montrées à cette personne ?
Le contexte n’est pas un amas de tokens. C’est un graphe avec du temps, de l’autorité et des frontières.
Davantage de contexte devrait produire davantage de preuves, pas davantage de confiance sans preuves.
La véritable unité de travail, c’est le changement
Les éditeurs et les outils de développement sont organisés autour des fichiers, parce que ce sont les fichiers que nous modifions. Les équipes d’ingénierie, elles, sont organisées autour des changements.
Un changement commence par une raison. Il devient une exigence, touche le code et les données, passe par la revue, arrive en production, puis crée de nouvelles preuves. Si ces étapes restent déconnectées, chaque tâche future recommence par une nouvelle séance d’archéologie.
Un système d’IA qui travaille sur un logiciel réel devrait suivre ce cycle de vie.
Avant l’implémentation, il devrait identifier la demande, les contraintes pertinentes et les éventuelles sources contradictoires. Il devrait savoir s’il corrige un défaut, modifie un comportement attendu ou introduit un nouveau contrat.
Pendant l’implémentation, il devrait relier chaque choix significatif à des preuves. Pourquoi ce module ? Pourquoi cette stratégie de migration ? Pourquoi conserver cette branche ? L’explication devrait survivre au-delà de la conversation qui a produit le code.
Après l’implémentation, il doit joindre au changement les résultats de vérification, les décisions de revue et les contraintes nouvellement découvertes. Sinon, la personne suivante — ou la prochaine session d’IA — devra les redécouvrir.
C’est la différence entre un outil capable de modifier un dépôt et un système capable de participer au travail d’ingénierie.
L’IA doit réduire la reconstruction, pas supprimer le jugement
Un meilleur contexte est parfois présenté comme une voie vers le développement logiciel autonome. La valeur immédiate est moins spectaculaire et plus utile : réduire le coût de reconstruction de la réalité avant d’apporter un changement.
L’IA peut rapprocher l’exigence d’origine du code concerné. Elle peut faire remonter l’incident qui explique une protection inhabituelle. Elle peut relier un indicateur en échec à la mise en production qui l’a modifié. Elle peut montrer que deux sources faisant autorité sont en désaccord avant même que l’implémentation ne commence.
Ces capacités ne suppriment pas le jugement d’ingénierie. Elles permettent de le fonder sur de meilleures informations.
Une personne doit toujours décider quel compromis est acceptable, si une exigence est complète et quel niveau de risque une mise en production peut porter. Le système doit rendre les éléments de preuve visibles et le raisonnement inspectable. Il ne doit pas dissimuler l’incertitude derrière un patch bien présenté.
Le critère n’est pas « peut-il générer du code ? »
Le critère est « peut-il expliquer pourquoi c’est le bon changement à faire maintenant ? »
D’une compréhension du dépôt à une compréhension du travail
Les assistants de code ont d’abord commencé à être utiles en comprenant le fichier devant le développeur. La compréhension du dépôt a été l’étape majeure suivante : trouver le code lié, suivre les symboles et appliquer des changements à l’échelle d’un projet.
L’étape suivante consiste à comprendre le travail autour du dépôt.
Cela signifie relier le code à la spécification qui l’a demandé, à la conversation qui l’a clarifié, aux éléments de production qui l’ont remise en question et à la décision dont il faudra se souvenir ensuite. Cela signifie aussi exclure le contexte qui n’est pas pertinent, qui est obsolète ou qui se trouve hors des autorisations de l’utilisateur.
En construisant Dvina, c’est l’une des idées auxquelles nous revenons sans cesse. Le travail ne se déroule pas dans un seul fichier, une seule application ou une seule conversation. Le sens réside dans les liens entre eux et dans la manière dont ces liens évoluent au fil du temps.
Le dépôt reste essentiel. C’est la source de vérité exécutable du comportement du système. Ce n’est tout simplement pas la source de vérité complète de l’intention produit, de la réalité opérationnelle ou de la mémoire organisationnelle.
L’histoire complète change ce qui est construit
Avec le seul code, la question naturelle est :
Quel changement convient à ce système ?
Avec un contexte plus large, la question devient :
Quel changement convient à ce système, à cette exigence, à cet historique et à ce moment précis ?
Cette deuxième question permet d’identifier les contraintes avant qu’elles ne deviennent des régressions. Elle donne aux relecteurs le raisonnement qui sous-tend l’implémentation. Elle aide les nouveaux membres de l’équipe à comprendre pourquoi le système est conçu ainsi. Elle donne à l’IA un rôle ancré dans le réel : non pas celui d’un oracle dans l’éditeur, mais celui d’un participant capable de rassembler des éléments de preuve à travers l’ensemble du travail.
Votre dépôt n’a jamais raconté toute l’histoire.
L’opportunité consiste à construire des systèmes capables d’en lire le reste — et de montrer leur travail.
