Aujourd'hui, l'intégration de l'IA agentique dans la conception et le développement informatique et notamment via des solutions comme Claude Code, Gemini Code Assist, Cursor ou OpenCode progresse de jour en jour.
Et c'est peu dire...
Avec eux, apparaissent des pratiques de développement telles que le vibe coding et le SDD.
Mais avec ces nouvelles pratiques apparaissent aussi de nouvelles contraintes, ralentissant l'assistance des agents IA pour le développement.
On voit alors de nouvelles manières de penser les solutions techniques.
La Developer Experience (DX)
Vous avez peut-être déjà entendu parler de la DX, la Developer Experience.
Ce concept qui désigne l'ensemble des pratiques, outils et choix techniques qui visent à réduire la friction dans le développement et la maintenance de nos applications.
Permettant ainsi à l'ensemble des développeurs de gagner du temps et d'être plus efficaces dans la réalisation de leurs tâches.
Cette expérience de développeur se traduit en différents points clés :
- Les outils : IDE utilisés et configurés, frameworks de test paramétrés et prêts à l'emploi.
- Les workflows : une documentation d'installation claire et simple, pas ou peu d'outils secondaires à installer, une procédure de développement, de code review et de test bien définie.
- Le code : un code concis, qui évite les "monster functions", avec des variables bien nommées, des erreurs compréhensibles et un fonctionnement intuitif qui respecte les normes du langage / framework utilisé.
Le respect des principes SOLID. Bref, du "bon code". - La documentation : Une documentation centralisée intelligible et bien écrite, des diagrammes et schémas lorsque c'est nécessaire.
L'Agentic Experience (AX)
Avant l'utilisation des agents de développement et plus globalement avant la mise à disposition des LLM grand public, les développeurs étaient tous humains.
Mais plus récemment, la proportion de développeurs IA vs développeurs humains évolue.
Alors, la DX évolue elle aussi, et on voit apparaître l'AX : l'Agentic Experience.
Les développeurs ne pensent alors plus uniquement aux autres développeurs humains, mais également aux agents de développement IA.
Pour comprendre ce que cela change concrètement, imaginons un nouvel arrivant dans votre équipe : il s'appelle Axel, et il n'est pas comme les autres développeurs.
Axel est un agent IA.
On lui donne un dépôt de code, une tâche, et il se met au travail.
Parfois, le résultat est impressionnant.
Parfois, beaucoup moins.
En réalité, le problème n’est pas vraiment Axel, mais plutôt l’environnement dans lequel il évolue :
- Sans contexte, il invente.
- Sans accès, il bloque.
- Sans outils, il devine.
C’est là qu’intervient une nouvelle manière de penser nos systèmes : l’Agentic Experience (AX).
Et pour la comprendre, il suffit de suivre Axel dans l'intégration de sa nouvelle équipe.
I. Le contexte
Axel débarque dans son nouveau projet, il n'y trouve aucune documentation, même pas un pauvre README.
Juste un dépôt Git et un prompt de son product manager qui lui demande d'implémenter le thème sombre dans l'application.
Axel se retrouve à inventer des fonctionnalités, des conventions, repenser l'architecture et produire un code impeccable... mais totalement incohérent.
En d'autres termes, il "hallucine".
Ce qu'il lui manque, c'est du contexte.
Ce contexte peut prendre plusieurs formes. La plus simple et la plus universelle reste le fichier Markdown à la racine du projet : CLAUDE.md, GEMINI.md, ou le standard émergent AGENTS.md.
Architecture générale, commandes clés, conventions de code, pièges à éviter : l'onboarding d'Axel doit passer par là.
Pour des projets plus costauds, on peut aller plus loin avec des skills : des fichiers de contexte spécialisés, qu'Axel activera uniquement quand il en aura besoin.
Plutôt que de tout charger d'un coup, il piochera l'information au bon moment.
Axel commence alors à devenir un vrai coéquipier : il connaît les patterns utilisés, les contraintes métier, les décisions techniques passées et surtout, pourquoi elles ont été prises.
II. L'accessibilité
Alors qu'Axel commence tout juste à prendre ses marques, son product manager le bombarde de prompts toutes les deux minutes.
Teste telle fonctionnalité de l'application...
Prends en compte la documentation sur telle URL...
Améliore la qualité de ton code en te basant sur les métriques Sonar...
Mais Axel ne sait pas comment récupérer toutes ces informations.
La problématique ici, c'est l'accessibilité.
Fin d'année 2024, Anthropic a imaginé le concept de serveur MCP (Model Context Protocol). Cette idée que chaque application pourrait développer une forme de protocole conçue pour communiquer avec les agents IA.
Cette idée n'en est plus une, de nombreux services l'implémentent aujourd'hui.
De nombreuses autres manières de faire communiquer Axel avec nos outils existent, plein d'autres verront sans doute le jour prochainement.
Cela montre bien que la manière dont l'information est communiquée évolue avec notre utilisation de l'IA.
Axel ne réfléchit pas comme un humain. En réalité, son modèle ne fait que prédire le token suivant le plus probable.
Une information disponible pour un humain, mais trop dispersée pour un agent, dans un mauvais format, derrière trop d’étapes, ou exposée sans structure claire sera difficilement, voire pas du tout exploitable par notre pauvre Axel.
Ces mauvaises pratiques ne seront que davantage révélées avec notre utilisation toujours croissante de l'IA.
Il devient alors important :
- De structurer ses données clairement
- De donner du contexte à l'IA, via des skills ou un system prompt, lui indiquant comment aller chercher ces données
- De s'assurer de toujours conserver une trace atteignable par nos agents IA
Et pour faire en sorte qu'Axel ait accès à notre documentation sur Confluence, nos tickets sur Jira et les rapports de qualité de son code sur SonarCloud, il est aussi très important de bien configurer ses outils ...
III. Les outils
En 2022, lorsque ChatGPT voit le jour, c'est une révolution.
Et chaque nouvelle version du modèle améliore grandement ses capacités.
Même si les différentes mises à jour des modèles récents sont toujours bonnes à prendre, les différences concrètes ne sont plus forcément ressenties par tout le monde.
Ce qui fait bien plus la différence aujourd'hui, ce sont les outils.
Le product manager d'Axel lui demande de résoudre un bug sur l'application.
Il lui communique les manipulations qu'il a effectuées pour reproduire le bug, les logs d'application qu'il a trouvé et il essaie tant bien que mal d'expliquer ce qu'il a vu s'afficher à l'écran.
Un développeur humain aurait alors tenté de reproduire ce bug lui-même et se serait fait sa propre analyse en regardant lui même les logs applicatifs.
Ce serait quand même bien pratique si Axel pouvait faire la même chose...
Et bien en réalité, c'est largement possible.
Mais il faut les bons outils.
Avec des outils tels que Chrome Devtools MCP ou Playwright MCP, Axel peut lui même effectuer ces manipulations.
Il pourrait aussi utiliser l'outil de ligne de commande de Jira, si on lui explique bien comment l'utiliser dans un skill, par exemple.
Axel devient alors autonome, peut identifier les problèmes à résoudre, les reproduire et les corriger.
De notre côté, on évite les copier-coller et on gagne du temps !
Avec les bons outils, on peut aussi demander à Axel d'imaginer, concevoir et déployer des applications.
Ainsi il devient autonome sur toute la chaîne de développement.
Et c'est exactement là que le sujet devient délicat. Parce que bien outiller un agent, ce n'est pas lui donner accès à tout. C'est lui donner accès à ce dont il a besoin, ni plus, ni moins.
Si Axel se retrouve avec trop d'outils à sa disposition, il pourra vite perdre du temps à chercher lequel utiliser, voire utiliser un outil qui n'est pas utile pour ce qu'on lui demande.
Pas besoin d'un tournevis, une clé à molette, de la peinture et une tronçonneuse quand notre seule tâche est de planter un clou.
Conclusion
Au début de son intégration, Axel improvisait. Aujourd’hui, il comprend, agit, vérifie... et parfois même, devance les autres développeurs plus expérimentés.
Il sait ce qu'il fait, ce qu'il peut faire et plus important encore : ce qu'il ne peut pas faire.
L'Agentic Experience n'est pas une révolution qui arrive, elle est déjà là. Et comme toutes les bonnes pratiques d'ingénierie, elle paraît évidente une fois qu'on l'a comprise, et coûteuse une fois qu'on l'a ignorée trop longtemps.
Contexte, accessibilité, outils : trois piliers qui ne demandent pas de tout refaire from scratch, mais de commencer à penser différemment.
À se demander, pour chaque décision technique :
- Est-ce qu'un agent pourrait travailler efficacement dans cet environnement ?
- Est-ce que l'information est au bon endroit, dans le bon format, et accessible ?
- Est-ce que ma demande, la documentation et l'ensemble des outils nécessaires sont atteignables par un agent IA ?
Alors, lors de votre prochaine contribution au développement d'un projet : pensez à Axel !
Ce qui est certain, c'est que la frontière entre outillage humain et outillage IA va continuer de s'estomper. Les protocoles vont se standardiser, les agents vont gagner en autonomie, et les équipes qui auront investi dans une bonne AX se retrouveront avec un avantage indéniable.
La question n'est plus vraiment "faut-il intégrer les agents dans son workflow de développement ?"
Mais plutôt : "est-ce que mon environnement est prêt à les accueillir ?"
