Comment j’utilise Codex pour revoir 15 projets sans abandonner le contrôle manuel

Il y a quelques années, l’idée de revoir sérieusement 15 projets logiciels en parallèle m’aurait semblé irréaliste. Je ne parle pas d’ouvrir 15 dépôts et de les parcourir rapidement. Je parle de contrôler régulièrement de vrais projets pour les bugs, les mauvaises hypothèses, les problèmes SEO, les erreurs de traduction, les incohérences de localisation, les tests manquants, les régressions et les morceaux de code ancien qui ne correspondent plus au reste du système.

Le facteur limitant n’a jamais été la vitesse de frappe. C’était l’attention. Chaque projet possède son histoire, ses conventions, ses edge cases et des morceaux de code qui paraissent incorrects mais existent volontairement. Une vraie revue demande de lire, chercher, comparer, exécuter des contrôles, puis seulement décider ce qui mérite d’être modifié.

Codex a changé pour moi l’économie de ce travail répétitif. Il peut effectuer un premier passage dans un repository, suivre les références, inspecter les fichiers liés, faire remonter des patterns suspects, proposer des tests et m’aider à enquêter sur des zones que j’aurais auparavant ouvertes une par une. La décision finale ne devient pas automatique. C’est la partie coûteuse avant la décision qui devient beaucoup plus rapide.

La règle la plus importante que j’en ai tirée est simple : je n’utilise pas Codex pour me retirer de la boucle de revue. Je l’utilise pour élargir cette boucle.

Le vrai goulot d’étranglement est la répétition, pas l’écriture du code

Avec un seul projet, on peut conserver énormément de contexte en mémoire. Avec plusieurs projets, cela ne passe plus à l’échelle. Les mêmes catégories de travail reviennent sans arrêt :

• rechercher des bugs similaires dans différents composants ;
• vérifier qu’un refactoring n’a pas laissé un ancien call site ;
• revoir les tests après un changement de comportement ;
• repérer des incohérences de metadata, de logique linguistique, de headings ou de liens internes ;
• comparer les clés de localisation et le contenu traduit ;
• chercher des erreurs non gérées et des edge cases ;
• vérifier qu’un « petit » changement n’a pas touché plus de fichiers que prévu ;
• lire des diffs simples individuellement mais très coûteux en cumulé.

Rien de tout cela n’est spectaculaire. Tout est important. Et lorsque le même type de revue doit être répété sur plusieurs codebases, son coût devient énorme.

C’est précisément là qu’un AI coding agent est le plus utile pour moi. Il absorbe la partie répétitive de l’espace de recherche et me laisse davantage d’attention pour le jugement.

Je commence par l’inspection, pas par l’autorisation de tout réécrire

Une manière très simple d’obtenir un mauvais résultat consiste à demander « revois tout le projet et corrige tout ». La demande semble efficace, mais mélange découverte, priorisation, architecture, implémentation et validation dans une seule tâche incontrôlée.

J’obtiens de bien meilleurs résultats en séparant ces phases.

inspect → explain findings → prioritize → change → validate → review diff

Je veux d’abord que l’agent comprenne la zone concernée et m’explique ce qu’il a trouvé. Je veux des chemins de fichiers précis, le code impacté, la raison pour laquelle quelque chose paraît suspect et l’impact probable. Les modifications viennent ensuite.

C’est important car une IA peut avoir tort avec beaucoup d’assurance. Un code qui paraît redondant peut exister pour un vieux navigateur, un edge case de paiement, une migration ou une règle métier impossible à comprendre depuis un seul fichier. L’inspection me permet d’arrêter une mauvaise hypothèse avant qu’elle ne produise un diff énorme.

Je traite les findings comme des pistes, pas comme des verdicts

Une bonne revue Codex ne se termine pas par « j’ai trouvé 17 problèmes ». Le nombre, seul, ne vaut presque rien. Je cherche des preuves.

Pour un finding réellement actionnable, je veux savoir :

• où se trouve le problème ;
• pourquoi c’est un problème ;
• quel comportement peut casser ;
• quel niveau de confiance mérite la conclusion ;
• quel contrôle peut la confirmer ou l’infirmer ;
• quel serait le plus petit correctif sûr.

C’est particulièrement important pour la sécurité, le SEO et la logique métier. Un agent peut signaler quelque chose à investiguer, mais une explication qui ressemble à un rapport de sécurité ne prouve pas une vulnérabilité. Une alerte SEO n’est pas automatiquement un problème de ranking. Une condition étrange n’est pas automatiquement du dead code.

L’IA réduit le coût de découverte des candidats. La vérification décide toujours ce qui est réel.

La boucle de validation rend le workflow fiable

La génération de code est la partie visible du développement assisté par IA. La validation est ce qui le rend exploitable en production.

Après une modification, je veux que la codebase réponde. Selon le projet, cela peut inclure :

• TypeScript ou un autre compiler/type checker ;
• le lint ;
• des tests unitaires et d’intégration ;
• un build check ;
• des recherches ciblées d’anciens noms ou call sites ;
• la lecture manuelle du diff final ;
• la vérification du comportement visible par l’utilisateur.

Les commandes exactes comptent moins que la boucle. L’agent fait une hypothèse, le repository renvoie une preuve et la décision suivante s’appuie sur cette preuve.

C’est aussi pour cela que j’apprécie les projets fortement typés pour le travail assisté par IA. J’ai écrit séparément pourquoi TypeScript fonctionne si bien avec Codex en production : les types transforment de nombreuses hypothèses erronées en feedback immédiat et lisible par la machine.

Certains types de revue se prêtent particulièrement bien à l’IA

Bugs et régressions

Un agent peut suivre une valeur à travers plusieurs fichiers, inspecter les callers, comparer des implémentations similaires et repérer des branches incohérentes. Cela aide à localiser l’origine possible d’un symptôme. Je vérifie malgré tout le comportement avant d’accepter la conclusion.

Tests

L’IA est utile pour repérer un comportement modifié sans couverture de test équivalente, proposer des edge cases et expliquer ce que protège vraiment un test existant. Elle peut aussi faire ressortir des tests qui valident des détails d’implémentation plutôt que le comportement utilisateur.

SEO

Le SEO technique comporte énormément de contrôle de cohérence : metadata, alternates linguistiques, règles d’indexabilité, liens internes, templates, génération de sitemap, redirects et conventions de pages. Un agent peut comparer ces règles dans une grande codebase plus vite que je ne pourrais ouvrir chaque route. Mais je sépare toujours la correction technique de la question beaucoup plus difficile : le contenu mérite-t-il réellement de se positionner ?

Localisation et traductions

C’est l’une des zones les plus répétitives d’un produit multilingue. L’IA peut comparer les clés, trouver les valeurs manquantes, détecter les mauvais mélanges de langues, vérifier les placeholders et signaler les locales qui ont dérivé structurellement. C’est beaucoup plus rapide que lire de gros objets de traduction à la main, même si le copy important exige toujours un jugement humain.

Cohérence après refactoring

Les gros refactorings échouent souvent pour des raisons banales : un ancien import subsiste, une route garde l’ancien nom de champ, une fixture de test utilise encore l’ancienne structure. La recherche à l’échelle du repository combinée à un agent qui comprend l’intention du changement est particulièrement utile.

Le travail parallèle n’aide que si les tâches sont indépendantes

Il est tentant de démarrer de nombreux agents et de les laisser tout modifier en parallèle. Cela peut augmenter le throughput, mais aussi multiplier conflits et hypothèses incompatibles.

Je considère donc le parallélisme comme un problème de coordination. Les audits indépendants sont de bons candidats : vérifier la localisation d’un projet pendant qu’un autre est revu pour les tests, ou inspecter plusieurs repositories séparés simultanément. Deux agents qui réécrivent la même architecture sans plan commun, c’est autre chose.

Plus le travail est parallèle, plus les frontières sont importantes : un projet clair, une tâche claire, une définition de terminé claire et un résultat qui peut être revu séparément.

L’objectif n’est pas de maximiser le nombre d’agents actifs. L’objectif est de maximiser le progrès utile et vérifiable.

Ce que je ne délègue pas aveuglément

• Décisions d’architecture : le modèle peut proposer des options, mais les trade-offs à long terme dépendent souvent d’un contexte absent du repository.
• Conclusions de sécurité : les findings demandent vérification, threat context et souvent des outils dédiés.
• Règles métier : le code peut être cohérent et implémenter malgré tout le mauvais comportement produit.
• Gros refactorings destructifs : un diff énorme est plus difficile à comprendre et plus facile à approuver trop vite.
• Déploiement en production : des tests qui passent n’éliminent pas le risque opérationnel.
• Revue finale : je veux comprendre ce qui a changé avant d’y associer mon nom.

Ce n’est pas parce que l’IA est inutile dans ces domaines, mais parce qu’une réponse plausible et fausse peut y coûter particulièrement cher.

La revue IA ne remplace pas l’analyse statique

Je ne considère pas Codex comme un remplacement des compilers, linters, tests, scanners ou du monitoring. Ces outils ont un avantage que l’IA n’a pas : ils sont étroits, déterministes et répétables.

Le workflow le plus solide les combine. Codex peut raisonner sur le contexte et suggérer où regarder. Les outils statiques peuvent imposer des règles précises. Les tests vérifient le comportement. Les logs et le monitoring montrent ce qui se passe réellement. Et la revue humaine relie tous ces signaux à l’intention du produit.

Sans ces feedback systems, je ferais moins confiance à l’IA, pas davantage.

Le plus gros gain de productivité est une meilleure allocation de l’attention

Il est facile de dire « Codex fait gagner du temps », mais cela décrit mal le changement pour moi.

La ressource rare en développement logiciel n’est pas le nombre de frappes au clavier. C’est l’attention de haute qualité. Avant les AI coding agents, une grande partie partait dans la découverte répétitive : rechercher les mêmes patterns, lire des fichiers similaires, suivre les références, vérifier qu’un changement s’est propagé partout, puis recommencer dans un autre repository.

Aujourd’hui je peux déléguer davantage cette première passe et réserver mon attention aux décisions difficiles à automatiser : le finding compte-t-il vraiment ? Le fix respecte-t-il l’architecture ? L’expérience utilisateur s’améliore-t-elle ? Le risque est-il acceptable ? Est-ce vraiment quelque chose que je veux shipper ?

C’est pourquoi maintenir et revoir plusieurs projets semble différent aujourd’hui. Je ne revois pas moins. Dans beaucoup de cas je peux revoir davantage, parce que la partie mécanique ne consomme plus tout le budget.

Le workflow auquel je fais confiance

1. Définir un objectif de revue étroit. Bugs, tests, SEO, localisation, refactoring ou autre sujet précis.
2. Laisser l’agent inspecter avant d’éditer. Je veux d’abord les preuves et les emplacements affectés.
3. Prioriser les findings. Tous les problèmes théoriques ne méritent pas une modification.
4. Garder les changements bornés. De petits diffs cohérents sont plus faciles à valider.
5. Exécuter les checks machine. Typecheck, lint, tests, build, recherches ou validation propre au projet.
6. Lire le diff manuellement. Je cherche les réécritures inutiles, hypothèses fausses, edge cases manquants et changements hors scope.
7. Vérifier les comportements importants. En particulier utilisateurs, argent, security, SEO et infrastructure de production.
8. Seulement ensuite passer au projet suivant. Le parallélisme est utile, mais l’incertitude non résolue ne doit pas se propager.

Quinze projets ne ressemblent plus à quinze fois plus de travail de revue

Codex n’a pas rendu 15 projets simples et n’a pas supprimé ma responsabilité. Il a changé la relation entre l’échelle et l’effort répétitif.

Je peux demander des premières passes plus profondes, des contrôles de cohérence plus larges, plus d’idées de tests et des audits plus systématiques sans passer personnellement chaque minute à chercher dans chaque fichier. Je peux ensuite consacrer l’attention économisée aux décisions qui nécessitent encore un développeur.

C’est cette forme de développement assisté par IA que je trouve utile : pas d’autopilot, pas de confiance aveugle, pas de « génère du code jusqu’à ce que quelque chose passe ». C’est une boucle plus serrée entre inspection à l’échelle de la machine et jugement à l’échelle humaine.

Pour moi, c’est le vrai levier de Codex. Il n’élimine pas la revue. Il rend possible une revue sérieuse à une échelle qui était auparavant bien plus difficile à maintenir.