Préparer sa base de code pour les agents IA en une semaine

Préparer une base de code pour les agents IA ne demande pas un trimestre. Une semaine d’un ingénieur senior suffit pour l’essentiel, et l’effet est immédiat : les mêmes agents, sur le même code, produisent des résultats sensiblement meilleurs quand le terrain est prêt. Voici la checklist que nous déroulons chez nos clients, jour par jour.

Le principe derrière chaque étape : un agent est aussi bon que le feedback que votre repo lui donne. Contexte écrit, commandes rapides, conventions explicites : tout ce qui aide un nouvel arrivant humain aide un agent, avec un multiplicateur, parce que l’agent, lui, lit tout ce qu’on lui écrit.

Jours 1 et 2 : les fichiers de contexte

Un fichier CLAUDE.md ou AGENTS.md à la racine, et un par module pour les gros repos, qui tient sur une page : comment lancer les tests, la carte de l’architecture en dix lignes, les conventions qui ne se devinent pas, les pièges connus ("ce module est en cours de migration, ne pas imiter l’ancien pattern").

Ce qui n’y va pas : la documentation exhaustive, les évidences ("écrire du code propre"), et tout ce qui se périme vite. Un fichier de contexte faux est pire qu’un fichier absent, parce que l’agent applique ce qu’il lit, erreurs comprises. Installez le réflexe de mise à jour dès maintenant : un diff qui change une convention met aussi le fichier à jour, et cela se vérifie en revue.

Jour 3 : des commandes rapides et fiables

Une commande pour tester, une pour linter, une pour builder, documentées dans le fichier de contexte, et rapides. Un agent itère au rythme de votre boucle de feedback : avec une suite de tests de trois minutes, il converge seul en quelques allers-retours ; avec quarante minutes, la délégation devient de l’attente. Si la suite complète est lente, exposez un sous-ensemble rapide par module et gardez la suite complète pour la CI.

Les tests instables sont le poison propre à cette étape : un agent qui reçoit un échec aléatoire "corrige" du code qui fonctionnait. Mettez-les en quarantaine avant de déléguer quoi que ce soit.

Jour 4 : les premières skills et un gabarit de tâche

Deux ou trois skills suffisent pour démarrer : vos conventions de test, votre checklist de revue, la procédure d’une tâche récurrente que l’équipe connaît bien (une migration, un endpoint, un composant). Une skill est un document court, versionné dans le repo, que l’agent charge quand la tâche s’y prête : c’est par elle que le savoir-faire d’un développeur devient celui de l’équipe.

Ajoutez un gabarit de tâche, c’est-à-dire le format dans lequel on rédige ce qu’on délègue. Le nôtre tient en quatre rubriques : le contexte, l’objectif, la définition de "fini" (tests verts, lint propre, documentation touchée si besoin), et les limites (ne pas toucher tel module, ne pas ajouter de dépendance). Une bonne part des déceptions avec les agents viennent en réalité de tâches mal spécifiées.

Jour 5 : les permissions et le périmètre

Décidez explicitement ce qu’un agent peut faire sans demander (lancer les tests, lire le repo, modifier des fichiers) et ce qui exige une validation humaine : installer une dépendance, toucher à la CI, exécuter une migration. Vérifiez que les secrets sont hors d’atteinte ; ils ne devraient déjà pas être dans le repo, c’est l’occasion de le confirmer. Commencez prudemment, puis élargissez chaque semaine en fonction de ce que vous observez. Ces choix ont leur place dans la politique IA de l’équipe, à côté des règles sur les données.

Ce cadre local s’articule avec les règles globales : les guardrails en CI restent le filet qui attrape ce que la configuration locale laisse passer, pour le code des agents comme pour celui des humains.

Comment savoir si la base de code est prête

Le test du vendredi : prenez trois tickets réels du backlog, ni choisis pour briller ni pour piéger, et déléguez-les. Regardez ce qui revient : combien de diffs sont mergeables sans retouche, où l’agent s’est perdu, quelle information lui a manqué. Les manques observés forment la liste des travaux de la semaine suivante, et le taux de "mergeable du premier coup" devient votre métrique de progression.

Cette semaine de préparation est le premier chantier de notre méthode de déploiement en équipe, avant le squad pilote. Si vous préférez la dérouler avec des gens qui l’ont déjà faite sur d’autres bases de code que la vôtre, c’est par là que commence notre offre d’ingénierie agentique.