Expertise - Agentic coding : développer avec des agents IA en gardant la qualité

Agentic coding et vibe coding

Le vibe coding consiste à décrire ce qu'on veut, à accepter ce que l'IA génère et à recommencer jusqu'à ce que ça ait l'air de marcher. Personne ne relit vraiment le code. Pour un prototype, ça va très vite, et c'est pour ça que tant de projets arrivent ensuite chez nous pour être industrialisés.

L'agentic coding part des mêmes outils. Un agent (Claude Code, Codex, Cursor en mode agent) travaille directement dans le dépôt : il lit le code existant, modifie plusieurs fichiers, lance les tests, lit les erreurs et corrige. Ce qui change, c'est le cadre autour de lui. La tâche est spécifiée avant qu'il commence, les tests décident si le résultat est bon, et un développeur senior relit avant que quoi que ce soit parte en production.

C'est comme ça que nous travaillons tous les jours chez Naeka.

---

Comment nous le pratiquons

Prenons une règle métier simple à ajouter dans une application de devis : un devis non signé expire au bout de 30 jours et ne peut plus être accepté.

1. La spécification. Le développeur écrit en quelques lignes ce qui doit se passer : le devis du 1er mars est encore acceptable le 31 mars, plus le 1er avril ; un devis expiré affiche un message clair ; un administrateur peut le prolonger. Il valide ces cas avec le client si besoin.
2. L'écriture. Un agent écrit le code et les tests sur une branche isolée, produit un commit, lance la suite de tests du projet et s'arrête.
3. La relecture. Un deuxième agent, qui n'a pas écrit le code, relance les tests lui-même et cherche les cas oubliés, comme le fuseau horaire ou le devis prolongé qui expire une seconde fois.
4. La couverture. On vérifie que chaque règle a un test, et que ce test échoue quand on casse la règle : si on passe la durée à 31 jours, un test doit tomber.
5. La décision. Le développeur relit, pousse, ouvre la merge request et répond à la review. Aucun agent ne pousse en production ni ne répond à un collègue à sa place.

L'écriture, la relecture et la couverture tournent en boucle jusqu'à ce qu'il ne reste que des remarques mineures. Le développeur passe donc son temps sur la spécification, les choix d'architecture et la relecture finale, et beaucoup moins à taper du code.

---

Ce qu'il faut dans un dépôt pour qu'un agent soit utile

Sur nos projets comme chez nos clients, ce sont presque toujours les mêmes points qui font la différence :

• un fichier AGENTS.md ou CLAUDE.md qui dit comment lancer les tests, quelles conventions suivre et ce qu'il ne faut jamais toucher ;
• un fichier REVIEW.md qui dit à l'agent de review ce qu'il doit vérifier en priorité, ce qui bloque une merge request et ce qui reste une simple remarque ;
• des tests rapides et fiables, parce que si la suite prend quarante minutes ou échoue au hasard, l'agent ne peut pas savoir s'il a cassé quelque chose ;
• une CI qui bloque la merge request en cas d'échec du lint, du formatage, des tests ou de l'analyse de sécurité, quel que soit l'auteur du code (voir notre expertise DevOps) ;
• des garde-fous : permissions limitées, secrets inaccessibles, pas de push automatique, commandes exécutées dans un environnement isolé ;
• un accès à votre contexte via le protocole MCP (Model Context Protocol), pour que l'agent lise un ticket, une documentation interne ou une erreur Sentry sans copier-coller.

---

Outiller vos équipes

Nous commençons par faire travailler un agent sur quelques tâches réelles de votre backlog, pour voir où il bute : tests absents, conventions jamais écrites, environnement local impossible à reproduire.

Ensuite, nous mettons en place ce qui manque dans vos dépôts (AGENTS.md, CLAUDE.md et REVIEW.md, agents de relecture et de couverture, intégration à votre CI). Nous choisissons avec vous les outils et les modèles selon la sensibilité de votre code, et nous fixons les règles d'accès aux secrets et aux données de production.

Pour savoir si l'agentic coding vous fait vraiment gagner du temps, nous suivons quelques indicateurs : temps de cycle, taux de retour en review, incidents.

---

Des skills et des plugins sur mesure

Un agent généraliste ne connaît ni vos conventions, ni vos process, ni vos outils internes. Les skills et les plugins servent à les lui apprendre.

Un skill est un ensemble d'instructions, parfois accompagné de scripts, que l'agent charge quand la tâche s'y prête : comment écrire une migration de base de données dans votre projet, quelles vérifications faire avant de toucher à la facturation, comment rédiger une note de version. Votre équipe écrit ces consignes une fois au lieu de les répéter à chaque demande.

Un plugin regroupe plusieurs briques dans un paquet que toute l'équipe installe en une commande : des skills, des agents spécialisés, des commandes, des hooks (des actions déclenchées automatiquement, comme lancer le lint après chaque modification) et des connecteurs MCP. Quand quelqu'un améliore une consigne, tous les développeurs en profitent à la mise à jour suivante.

Nous en développons pour nos propres projets, où le cycle décrit plus haut tourne avec notre plugin interne, et pour nos clients. Par exemple :

• un agent de review qui suit votre REVIEW.md : vos conventions de code, vos choix d'architecture et ce que vous avez appris de vos incidents de production ;
• un skill métier qui connaît une contrainte de votre secteur, comme les règles d'hébergement des données de santé en e-santé, et la vérifie dès qu'une modification touche ces données ;
• une commande de release qui prépare le changelog, le tag et la merge request en suivant votre process ;
• un hook qui bloque toute commande visant la base de production ou exposant un secret ;
• un connecteur MCP vers votre back-office, votre outil de tickets ou votre documentation, pour que l'agent travaille avec vos vraies données au lieu de deviner.

Nos skills fonctionnent aussi bien avec Claude Code qu'avec Codex. Votre équipe peut utiliser l'un ou l'autre, ou changer d'outil plus tard, sans tout réécrire. Ces briques sont versionnées dans un dépôt Git comme le reste de votre code : elles vous appartiennent et votre équipe peut les faire évoluer sans nous.

---

Former vos développeurs

Nos formations se font sur votre code et avec vos tickets. Vos développeurs y apprennent à :

• écrire une spécification qu'un agent peut exécuter : découper la tâche, poser les cas limites, reconnaître les cas où il est plus rapide de coder soi-même ;
• relire du code généré et repérer les erreurs typiques d'un agent, comme le test qui vérifie le mock plutôt que le comportement, la gestion d'erreur qui avale l'exception ou la dépendance inventée ;
• transformer les consignes que l'équipe répète à l'agent en skills partagés ;
• organiser le travail en boucle, avec un agent qui écrit, un qui relit, un qui vérifie la couverture, et un humain qui décide.

Un développeur Naeka peut aussi travailler quelques jours en binôme avec votre équipe sur de vraies tâches, jusqu'à ce que la méthode tienne sans nous.

---

Les limites

L'agent ne connaît pas votre métier. Il applique ce qu'on lui dit avec assurance, y compris quand c'est faux, donc la spécification reste un travail humain. Il se trompe aussi sans le signaler : un test vert ne prouve rien si le test est mal écrit, d'où la passe couverture.

Il a un coût. Les abonnements et la consommation de tokens se mesurent, et certaines tâches reviennent plus cher avec un agent qu'à la main.

Enfin, il ne remplace pas l'expérience. Un développeur junior avec un agent produit plus de code, et il lui faut toujours quelqu'un pour juger si ce code est bon.

Pourquoi choisir Naeka ?

Nous utilisons ces outils sur nos propres projets en production. Nous connaissons aussi la suite : l'industrialisation de prototypes issus du vibe coding, le déploiement sur Kubernetes et la maturité de production. Ça nous aide à mettre l'agentic coding là où il fait gagner du temps sans créer de dette technique.

Nos ingénieurs peuvent aussi rejoindre votre équipe en tant que Forward Deployed Engineer et appliquer cette méthode sur vos sujets.

Envie de passer à l'agentic coding ?

Que vous vouliez outiller vos dépôts, former vos développeurs ou confier un développement à une équipe qui travaille déjà comme ça, contactez-nous. Nous commençons en général par faire travailler un agent sur quelques tâches de votre backlog, pour voir ce que vous pouvez y gagner.