Coder avec des agents IA en tâche de fond : notre workflow réel

L'été StartingUp continue. Prendre de la hauteur sur une année dense, c'est aussi ouvrir les portes de l'atelier. Après avoir refermé le tiroir des questions que l'IA a rendues obsolètes, nous racontons ce qu'elle a changé de plus profond chez nous : coder avec des agents IA en tâche de fond est devenu notre quotidien, décrit ici sans filtre.

Vous avez forcément croisé la promesse : des développeurs remplacés par un chatbot, des logiciels entiers écrits tout seuls pendant la nuit. Ce que nous vivons à l'agence est à la fois moins spectaculaire et beaucoup plus intéressant. Oui, une grande partie de notre code s'écrit désormais avec des agents IA : des instances d'intelligence artificielle qui reçoivent une mission précise, disposent d'outils réels (lire le code, exécuter des commandes, lancer les tests) et travaillent seules pendant de longues minutes, souvent en tâche de fond, pendant que nous faisons autre chose. Non, personne n'a été remplacé.

Cet article est un retour d'expérience, pas un argumentaire : il décrit ce fonctionnement tel qu'il est vraiment, victoires et galères comprises. Aucune démonstration de laboratoire : uniquement des situations vécues cette année sur des projets clients.

Coder avec des agents IA tient en trois temps : spécifier une mission cadrée, la confier à un agent qui travaille en tâche de fond avec de vrais outils, puis vérifier tout ce qui revient (tests, revue, essais réels) avant la moindre mise en production. Le reste de cet article détaille chaque poste de ce workflow.

L'image du développeur qui dicte son code à un assistant est fausse. La bonne image est celle d'un chef d'orchestre : il ne joue plus chaque note lui-même, mais il choisit la partition, distribue les pupitres, écoute tout ce qui se joue et arrête net ce qui sonne faux. Notre journée type consiste à découper le travail en missions parallèles, à les confier à des agents, puis à relire et arbitrer ce qui revient.

Un exemple vécu. Sur une plateforme e-commerce, nous avons livré en une seule session une fonctionnalité complète de recherche vidéo : termes de recherche personnalisés par langue, ajout manuel par URL, déduplication des résultats. Plusieurs agents ont travaillé en parallèle, chacun sur son périmètre. En fin de session : plus de 380 tests automatisés au vert et zéro erreur de typage. Ce qui a occupé l'humain pendant ce temps n'était pas de taper du code, mais de trancher : quelle architecture, quelles limites, qu'est-ce qui part en production et qu'est-ce qui attend.

Autre registre, même logique : pour une boutique spécialisée, un article de fond d'environ 3 000 mots est passé par un pipeline complet, recherche concurrentielle, rédaction, puis trois agents d'optimisation SEO lancés en parallèle et une quinzaine de corrections appliquées après relecture. La partie la plus décisive n'était pourtant pas automatisable : l'angle éditorial qui manquait dans les résultats de recherche (écrire du point de vue de l'expert métier, pas du prestataire) est un choix, pas un calcul. Et une galère, pour l'honnêteté : ce jour-là, les agents en arrière-plan ne pouvaient pas enregistrer eux-mêmes leurs fichiers, il a fallu récupérer leurs résultats à la main. Le « lancer et oublier » est un objectif, pas encore un acquis.

Migrations de données, suites de tests à écrire, refontes mécaniques, mises à jour de dépendances : tout ce qui est long, cadré et vérifiable part en tâche de fond. L'agent avance, nous continuons sur le reste, et nous reprenons la main au moment de la relecture. C'est le même esprit qui nous avait conduits à brancher WordPress sur Claude via MCP : donner aux agents un accès outillé, cadré et révocable à nos systèmes, plutôt que de copier-coller des bouts de code dans une fenêtre de discussion.

Sur un site e-commerce sous PrestaShop, un module de suivi publicitaire refusait obstinément de s'exécuter : enregistré en base de données, actif, correctement accroché... mais jamais appelé lors des requêtes web. Deux heures d'enquête méthodique, hypothèse après hypothèse, pour découvrir qu'une installation insérée manuellement en base n'est pas une installation complète aux yeux de la plateforme. L'agent teste et vérifie bien plus vite que nous ; l'humain garde le fil, apporte le contexte (le scénario de redirection en cause était impossible à reproduire en local) et tranche au final pour une solution ceinture et bretelles.

Ces sessions rappellent aussi que l'environnement ment autant que le code. Un piège classique : une bibliothèque installée dans un conteneur Docker mais jamais déclarée dans les dépendances du projet. Tout fonctionne, jusqu'au jour où le conteneur est reconstruit : page blanche. Face à ce genre de bug, l'agent est aussi aveugle que nous ; ce qui sauve, c'est la méthode (reproduire, isoler, prouver), pas la puissance du modèle.

Rien de ce qu'un agent produit n'entre dans un projet sans relecture. Notre pratique la plus rentable : une double revue, d'abord de conformité (le travail correspond-il exactement à ce qui était spécifié ?), puis de qualité (le code est-il sain, testé, défensif ?), souvent confiée à d'autres agents avant l'arbitrage humain. Cette mécanique a récemment attrapé, sur un chantier WordPress, un paramètre erroné répété dans sept fichiers de configuration : des pans entiers de l'interface d'administration auraient été invisibles, silencieusement, jusqu'à la première utilisation réelle. Les tests étaient verts. Sans revue, le bug partait en production.

Aucun agent, chez nous, ne peut déployer, supprimer des données ou publier quoi que ce soit sans validation humaine explicite. Ces règles sont écrites dans la configuration de nos outils, pas dans un vague code de conduite, et elles mordent régulièrement : l'agent s'arrête, explique ce qu'il veut faire, et attend. La friction est réelle, et elle est saine. Le jour où une synchronisation trop large a emporté du code qu'elle n'aurait pas dû toucher, tout a été restauré en quelques minutes, précisément parce que rien ne contourne jamais le contrôle de version ni la validation humaine.

• Le boilerplate et la mécanique répétitive. Mise en place de projets, configuration, code d'infrastructure : qualité constante, vitesse déconcertante.
• Les migrations et transformations de masse. Appliquer le même changement à des dizaines de fichiers ou de contenus, sans fatigue et sans oubli.
• Les tests. Écrire une couverture de tests sérieuse n'est plus la corvée que l'on repousse : des suites entières naissent en quelques heures et rattrapent de vrais bugs.
• L'investigation de bugs. Formuler des hypothèses, les vérifier une à une, éplucher des journaux d'erreurs sans se décourager : l'agent excelle dans l'enquête, tant qu'un humain garde le cap.

• Le contexte métier long. Un agent démarre chaque session presque vierge. Tout ce qui fait l'histoire d'un projet (pourquoi ce choix il y a deux ans, ce que ce client ne veut surtout pas) doit être documenté ou répété. La documentation est devenue une infrastructure critique, plus une politesse.
• Le goût. Sur les micro-décisions de design, de wording, d'expérience utilisateur, l'agent propose du correct, rarement du juste. La direction artistique et le sens du détail restent humains.
• La dette de relecture. La plus sournoise : le code généré non relu est une dette. La vitesse de production a dépassé la vitesse de relecture, et accepter sans relire revient à accumuler du code que personne dans l'équipe ne comprend vraiment.

Ce dernier point mérite d'être dit sans détour aux décideurs : la nouvelle dette technique ne se voit pas dans les délais, elle se voit six mois plus tard, quand il faut faire évoluer un code que personne n'a jamais lu. Un prestataire qui livre vite grâce à l'IA sans processus de revue ne vous fait pas gagner du temps, il vous en emprunte.

On nous demande parfois s'il faut former les équipes au « prompt engineering ». Notre réponse, après une année d'usage intensif : pas vraiment. Parler aux modèles s'apprend en quelques jours. Les deux compétences qui prennent de la valeur sont plus anciennes et plus exigeantes : spécifier (décrire précisément ce que l'on attend, les contraintes, les critères qui permettront de dire que c'est fini) et vérifier (prouver que cela fonctionne, par des tests, des revues et des essais en conditions réelles, plutôt que de le croire sur parole).

C'est peut-être la meilleure nouvelle de cette bascule : elle ne récompense ni le jargon ni les outils à la mode, mais la rigueur. Un développeur rigoureux épaulé par des agents va beaucoup plus vite qu'avant ; un développeur négligent aussi, et c'est précisément le problème. Si l'on vous promet des miracles grâce à l'IA, une seule question fait le tri : demandez comment le code est relu.