Repenser l'organisation du code et des environnements à l'ère de l'IA

On parle beaucoup de modèles plus puissants les uns que les autres, d’IDE augmentés (Cursor, Claude Code). On parle aussi d'agents capables d’ouvrir une pull request ou de corriger un bug. Ce sont les démos que l’on voit tous et qui sont bien souvent spectaculaires.

Pourquoi alors, lorsque déployé dans des équipes techniques sur des projets réels les agents IA semblent moins capables ? C’est peut-être moins l’agent lui-même qui fait défaut que le terrain sur lequel on le fait travailler. Un agent de développement n’a rien de magique : pour produire un résultat utile, il doit comprendre le système, modifier le code, lancer les bons outils, vérifier son travail et s’inscrire dans les règles de l’équipe. Autrement dit, il dépend de deux choses très concrètes :

• la manière dont le code est organisé ;
• et de l’environnement de travail

C’est là que l’IA rend certains fondamentaux impossibles à ignorer. Une codebase fragmentée, une CI fragile, un setup local compliqué, des variables d’environnement non documentées : tout cela pénalisait déjà les développeurs. Les agents rendent ces problèmes plus saillants.

Le harness : clarifier ce qu’on met derrière un agent

Un agent IA de développement n’est pas seulement un modèle de LLM auquel on demande de coder. Le modèle est prépondérant, c’est sûr, mais il y a aussi les instructions, les outils, les conventions projet, les méthodes de travail, les accès, les commandes disponibles, les garde-fous et l’environnement d’exécution dans lequel l’agent peut agir.

Cette notion est extremment importante en matière d’IA s’appelle le harness, terme qui n’a pas de traduction française parfaite dans ce contexte. On peut le comprendre comme le cadre opérationnel de l’agent : ce qui l’entoure, l’oriente, lui donne ses outils et lui permet de boucler entre compréhension, action et vérification.

Dans le harness, il y a une partie instructionnelle : prompts, règles, skills, qui peuvent contenir des méthodologies, des procédures, des conventions.

Il y a aussi une partie très matérielle, les capacités de l’agent pour accèder au dépôt, à un terminal, à un conteneur, à pouvoir lancer les tests et lire leur rapport d’éxécution, à pouvoir linter le code, à pouvoir builder l’application, à pouvoir accéder à une base de données locale, à pouvoir générer des fixtures etc.

Un agent qui ne peut que lire le code reste un assistant. Un agent qui peut comprendre, exécuter et vérifier offre de vraies perspectives de productivité.

Le code source fait parti du contexte

Toute éxécution agentique a besoin d’un contexte qui permettra à l’agent de pouvoir produire la réponse la plus pertinente possible. Qu’y a-t-il de plus précis que le code pour contextualiser un agent de développement ? Toute demande, si augmenté du code de l’application permettra à l’agent d’être le plus pertinent possible. Et cette affirmation secoue certaines habitudes.

Pendant longtemps, il a été courant de séparer un produit en plusieurs dépôts de code. Prenons un exemple simple, pour une application mobile, bien souvent il fallait un dépôt de code pour l’application mobile en elle même, un autre pour l’API et le backoffice dont elle allait dépendre, et pourquoi pas un dernier pour l’infrastructure as code. Ce découpage pouvait avoir du sens. Il reflétait parfois les équipes, les responsabilités, les cycles de release ou simplement l’histoire du projet. À l’ère des agents, ce découpage devient moins neutre : une fonctionnalité réelle traverse rarement une seule couche technique. Elle peut impliquer une interface mobile, une route API, une règle métier, une migration de base de données et pourquoi pas un nouveau composant d’infrastructure..

Si ces éléments sont répartis dans plusieurs dépôts, le contexte est fragmenté. C’était déjà un frein pour les humains ; cela devient encore plus visible avec les agents. Dans son retour d’expérience sur River, Shopify raconte d’ailleurs que son choix récent du monorepo global, pensé au départ comme un pari d’infrastructure, s’est révélé déterminant pour déployer des systèmes agentiques à grande échelle.

Pour une entreprise produit comme Shopify, le choix du monorepo global peut se défendre. En ce qui concerne les agences telle que Dernier Cri, ce n’est évidemment pas une option : nous travaillons pour plusieurs clients, avec des contraintes de confidentialité, de gouvernance et de propriété intellectuelle. Mélanger toutes les codebases dans un seul dépôt n’aurait aucun sens. En revanche, pour un même client, un même produit ou un même système cohérent, le monorepo devrait devenir un réflexe beaucoup plus naturel.

L’approche monorepo pose de nouvelles contraintes d’architecture, car un monorepo n’est paradoxalement pas moins complexe que plusieurs dépôts. Il faut continuer à organiser les domaines, clarifier les responsabilités, isoler les modules, documenter les décisions, limiter les dépendances inutiles. Cependant, lorsque c’est bien mené, le dépôt devient alors un espace de contexte partagé. L’agent peut naviguer dans le produit complet, tout comme le développeur. Les décisions d’architecture, les scripts, les tests, les workflows CI et l’infrastructure vivent dans un même espace de travail.

Les impacts pour la mise en place d’une telle structure de code sont :

• revoir la CI pour déclencher les bons pipelines selon les changements. Ex: ne pas builder l’application mobile si seul le backend a été modifié.
• garder une exécution des tests rapide. Une pyramide de tests respectée sera particulièrement efficace.

Mais la nécessité de mettre en place une telle structure de code devient de plus en plus évidente et de nombreux de nos clients ont déjà fait le pas.

L’environnement fait partie du harness

Comprendre le code ne suffit pas. Un agent doit pouvoir agir. C’est le fameux harness que nous avons déjà évoqué.

Chez Dernier Cri, nous investissons depuis plusieurs années dans les environnements reproductibles pour les développeurs, notamment avec les devcontainers et les conteneurs de manière générale. L’arrivée des agents IA ne fait que renforcer cette conviction.

Ce qui permet à un humain de démarrer vite permet aussi à un agent de travailler correctement.

Si un développeur doit passer trois heures à installer une version implicite de Node, comprendre une variable d’environnement transmise oralement, retrouver une commande de seed jamais documentée ou demander à un ancien du projet pourquoi le test échoue en local, l’agent ne fera pas mieux par magie. Il échouera plus vite, ou plus silencieusement. Dans les deux cas, il faudra le superviser en permanence.

Les conteneurs sont aussi par nature des environnements de type sandbox. Ils permettent de s’isoler du reste de l’infrastructure et de tester des scénarios sans interférences. Les agents peuvent y exprimer leur plein potentiel sans nécessité d’une supervision humaine à chaque exécution de commande.

Dans tous les cas, un environnement reproductible et instrumenté devient donc une pièce du harness. Chez nous, ça se traduit concrètement par :

• un devcontainer ou une image Docker capable de lancer le projet ;
• des commandes standardisées pour installer, démarrer, tester, linter, builder ;
• des variables d’environnement documentées ;
• des seeds et fixtures utilisables localement ;
• une base de données de développement facile à recréer ;
• une CI qui exécute les mêmes chemins que l’environnement de développement ;
• des procédures écrites dans le dépôt plutôt que transmises uniquement à l’oral.

On peut voir cela comme une contrainte supplémentaire mais c’est plutôt l’inverse : c’est toujours payant à terme. Un projet qui démarre vite, se teste facilement et est bien documenté est quoi qu’il arrive un meilleur projet pour les humains. Les agents ne font que rendre cette exigence plus rentable.

Au final, agent-friendly veut souvent dire human-friendly

‍

Le point le plus intéressant n’est pas que les agents imposeraient des pratiques entièrement nouvelles, c’est plutôt qu’ils remettent de la valeur sur des pratiques que les bonnes équipes défendent déjà depuis longtemps : un environnement reproductible, une CI lisible, une documentation et une infra as code, des conventions explicites, des commandes de productivité simples, des frontières de modules compréhensibles, une organisation du dépôt qui reflète le produit. Tout cela était déjà utile… et avec les agents tout cela devient structurant.

Rendre un système plus accueillant pour les agents revient donc souvent à le rendre plus accueillant pour les humains et c’est probablement une très bonne chose. Au passage, je n’avais pas m’empêcher de noter que le CLI Google Workspace, sorti début 2026 par Google, se décrivait avant toutes choses comme “built for humans and AI agents”. N’est-ce pas un indice qu’une base de code moderne est vertueuse ? Les agents amplifient les qualités et les défauts du système dans lequel on les intègre et ce que l’on fait pour les agents, on le fait aussi pour les humains.