Stack IA — Travailler sur du code existant

1 · Explorer

Prendre en main une base inconnue

C’est le meilleur cas d’usage d’un agent, et de loin. Ce qui prenait deux jours de lecture prend une heure — à condition de poser les bonnes questions.

1

La carte avant le détail

Quels sont les modules principaux, qui appelle qui, où entre une requête et où elle ressort. Une vue d’ensemble avant toute plongée.

2

Suivre un parcours réel

« Trace le chemin complet d’une connexion utilisateur, fichier par fichier. » Un parcours concret apprend plus que dix descriptions d’architecture.

3

Repérer les zones sensibles

Quels fichiers changent le plus souvent, lesquels n’ont aucun test, où se concentre la complexité. C’est là que le risque vit.

4

Faire expliciter les conventions

Comment ce projet nomme, structure, gère ses erreurs. Ces règles implicites deviendront ton fichier d’instructions.

Premier contact avec un repo

Tu découvres ce projet avec moi. Lecture seule :
ne modifie rien.
1. Donne-moi la carte des modules principaux et
   leurs responsabilités.
2. Trace le parcours complet de [une action clé],
   fichier par fichier.
3. Liste les conventions implicites que tu observes
   (nommage, structure, gestion d'erreur, tests).
4. Signale les zones qui te semblent fragiles ou
   inhabituelles, et pourquoi.
5. Termine par les 5 questions que tu poserais à
   l'auteur d'origine.
Sois factuel : si tu n'es pas sûr, dis-le.

Le livrable qui rentabilise l’exploration : transforme ces réponses en fichier d’instructions projet. Ce que l’agent vient de comprendre sera perdu à la fin de la session — sauf si tu l’écris.

2 · Modifier

Changer sans casser ce qui marche

Le risque n’est pas le code que tu écris, c’est le code que tu ne connais pas et qui dépend de ce que tu modifies.

Avant

Chercher les appelants

« Qui utilise cette fonction, et comment ? » Un agent qui n’a pas cherché suppose qu’il n’y a qu’un seul appelant — et casse silencieusement les autres.

Avant

Poser un filet de tests

Sur du code non testé, écris d’abord des tests qui décrivent le comportement actuel, même s’il est bizarre. Ils protègent la modification à venir.

Pendant

Respecter le style local

Un agent applique volontiers ses propres conventions. Sur du legacy, la cohérence avec l’existant vaut mieux que la « bonne pratique » importée.

Pendant

Interdire le nettoyage spontané

« Corrige ce bug, ne touche à rien d’autre. » Sinon tu récupères un diff où ta correction de trois lignes est noyée dans du reformatage.

Après

Vérifier les effets de bord

Ce qui dépendait du comportement modifié fonctionne-t-il encore ? C’est la question que le code legacy punit le plus durement.

Attention

Le code bizarre a souvent une raison

Une condition étrange cache parfois un correctif de production oublié. Avant de « simplifier », demande pourquoi ça pourrait exister — et cherche dans l’historique.

3 · Refactorer

Par petits pas, jamais d’un bloc

« Refactore ce module » est la demande la plus risquée qu’on puisse faire à un agent. Elle produit un diff énorme, impossible à relire, où le moindre bug devient introuvable.

✗ Le refacto d’un bloc

Un seul message, huit cents lignes modifiées, comportement réécrit et structure changée en même temps. Si un test tombe, tu ne sais pas lequel des vingt changements en est la cause.

✓ Le refacto en escalier

Une transformation à la fois, testée et commitée avant la suivante : extraire une fonction, puis renommer, puis déplacer, puis simplifier. Chaque étape est réversible et relisible.

Ne jamais mélanger structure et comportement dans le même commit : la relecture devient impossible.

1

Sécuriser d’abord

Des tests qui décrivent le comportement actuel. Sans eux, un refacto est un pari, pas une opération d’ingénierie.

2

Ne jamais mélanger structure et comportement

Soit on déplace du code sans rien changer, soit on change le comportement. Les deux dans le même commit rendent la relecture impossible.

3

Commiter à chaque palier

Un commit par transformation, avec la suite verte. C’est ce qui permet de revenir en arrière sans tout perdre.

4

Accepter l’imparfait

Améliorer la zone que tu touches suffit. Vouloir tout réécrire d’un coup est la façon la plus fiable de casser un système qui fonctionnait.

4 · Migrer

Changer de version ou de techno

Les migrations sont le terrain où un agent fait gagner le plus de temps : c’est répétitif, mécanique, et bien documenté. À condition de cadrer.

La méthode qui marche : faire produire un inventaire d’abord (tout ce qui utilise l’ancienne API, classé par difficulté), puis migrer par lots homogènes, avec les tests verts entre chaque lot.

Le piège spécifique : la date de coupure du modèle. Sur une version sortie après son entraînement, il appliquera l’ancienne API avec assurance. Fais-lui lire le guide de migration officiel plutôt que répondre de mémoire.

Cadrer une migration

Migration : [de X vers Y].
Étape 1 — inventaire, sans rien modifier :
liste tous les endroits qui utilisent l'ancienne API,
groupés par type de changement, du plus simple au
plus risqué. Signale ceux qui demandent une décision
humaine.
Important : lis le guide de migration officiel avant
de répondre, ne te fie pas à ta mémoire — la version
cible est peut-être postérieure à tes connaissances.
Étape 2 : on migrera lot par lot, tests verts entre
chaque lot. N'entame rien avant que je valide
l'inventaire.

Vérifie que c’est acquis

Tu tombes sur une condition bizarre dans du code ancien, sans commentaire ni test. L’agent propose de la simplifier. Quel est le bon réflexe ?

À retenir

Comprendre avant de changer

Fais explorer et cartographier avant toute modification, cherche systématiquement les appelants, pose des tests sur le comportement existant avant d’y toucher, refactore par petits pas commités, et méfie-toi du code bizarre : il a souvent une histoire.