Tu sais coder. Tu as passé du temps à apprendre, à chercher des erreurs, à comprendre pourquoi une solution fonctionne et une autre finit par casser.
Alors, quand tu vois quelqu’un demander à une IA de générer une fonctionnalité en quelques phrases, tu peux ressentir une certaine résistance.
Pas forcément parce que l’outil est mauvais. Parfois, parce que tu ne veux pas que ton travail ressemble à du code accepté sans compréhension.
Cette prudence a sa place. Mais elle ne devrait pas devenir une interdiction d’essayer.
Le débat sur les mots cache parfois le vrai sujet
Dans mon article sur le vibe coding, je m’adressais notamment aux personnes qui veulent créer un outil sans savoir coder. J’y insistais déjà sur le contexte, le découpage et la vérification. Le propos n’était donc pas d’accepter aveuglément ce que produit l’IA.
Ici, je m’adresse à toi qui sais coder, mais hésites à utiliser ces outils par peur de dévaloriser ton travail. Le sujet n’est plus de découvrir la méthode : c’est de trouver la place de ton expertise dans cette collaboration.
Les termes prêtent parfois à confusion. Dans cet article, j’emploie « développement agentique » pour parler du travail confié à un agent capable d’enchaîner des actions dans un projet. Cela ne dit pas, à lui seul, si le résultat est sérieux. Ni « vibe coding » ni « agentic coding » ne sont des certificats de qualité.
On peut utiliser un agent capable de modifier tout un projet et accepter son résultat sans le lire. On peut aussi lui confier une petite tâche, examiner son explication, vérifier le code et refuser sa proposition.
L’agent décrit une capacité de l’outil. La rigueur décrit ta manière de travailler.
C’est cette deuxième partie qui m’intéresse.
Ton expérience change les questions que tu poses
Sur une application métier, un développeur expérimenté ne regarde pas seulement si l’écran fonctionne.
Il pense aux droits d’accès, aux données incohérentes, à une opération rejouée deux fois, aux effets sur les utilisateurs existants.
Cette expérience reste utile avec l’IA. Elle aide à voir ce qu’une démonstration réussie ne montre pas.
Tu peux demander à l’outil de préparer une implémentation. Mais déterminer les risques à examiner, puis décider si le résultat est acceptable, fait toujours partie du travail.
Ce n’est pas une perte de compétence. C’est une autre façon de l’exercer.
Ce que tu peux déléguer, ce que tu dois assumer
Tu peux confier à l’IA la recherche des fichiers concernés ou une première proposition de correction. Tu n’es pas obligé de lui céder l’arbitrage sur les règles métier, l’architecture ou les risques acceptables.
Imagine une correction qui fait passer les tests en supprimant une vérification de permissions. L’outil a peut-être supprimé le symptôme. Ton rôle est de voir qu’il a aussi supprimé une protection.
C’est là que ton expérience intervient : distinguer une solution qui fonctionne dans le cas montré d’une solution que l’équipe peut réellement livrer.
Enfin, pose-toi une question honnête : pourrais-je expliquer cette modification à un collègue sans demander à l’IA de parler à ma place ?
Si la réponse est non, le travail n’est pas encore terminé.
Solo : donner une organisation au travail des agents
Quand plusieurs agents interviennent, une autre difficulté apparaît : savoir qui fait quoi, avec quelles informations et dans quel ordre. Que tu sois sceptique ou déjà convaincu, c’est un problème concret.
Solo propose une orchestration entre outils : un agent peut en lancer d’autres, leur répartir le travail et récupérer leurs résultats. Son site présente cinq éléments sous l’expression « Small building blocks for serious workflows » :
- Scratchpads : des notes Markdown partagées pour conserver le contexte au-delà d’une conversation. Tu peux y poser, par exemple, les règles métier d’un export et les décisions à respecter lors de sa correction.
- Todos : des tâches avec un suivi des blocages et des dépendances. Une vérification peut ainsi attendre la fin d’une implémentation, plutôt que de démarrer sur un travail incomplet.
- Prompt templates : des consignes réutilisables, avec des champs à compléter. Tu peux préparer un modèle de demande de revue, puis l’adapter au module concerné. Documentation de ces fonctions
- Control terminals : les agents peuvent lire les sorties des terminaux, envoyer des commandes et surveiller leur exécution. Pour un test, l’intérêt est de pouvoir examiner son résultat réel avant de décider de la suite.
- Agent spawning : un agent peut en lancer un autre, lui confier une mission et récupérer son résultat, y compris avec un outil d’un autre fournisseur. C’est ce qui permet de répartir le travail entre plusieurs intervenants. Présentation de Solo
Ce qui m’intéresse, c’est la façon de combiner ces éléments autour d’un besoin précis.
Imagine un export de factures à corriger dans une application Laravel. Voici un scénario que l’on pourrait organiser : consigner les contraintes métier, demander une analyse du parcours, confier la correction à un agent, puis faire examiner le changement par un autre. La revue dépend de la correction ; elle ne doit pas porter sur une ancienne version du code.
On obtient alors un travail avec des étapes, des responsabilités et des points de contrôle. Le deuxième agent apporte un regard supplémentaire, mais son accord ne suffit pas à valider le résultat. Tu gardes la responsabilité de comprendre et de vérifier ce qui sera livré.
Réserver les modèles les plus capables aux décisions difficiles
Cette organisation permet aussi de réfléchir au budget. Voici une stratégie que je proposerais : confier le cadrage, le découpage et les arbitrages à un agent utilisant un modèle plus capable, puis attribuer les tâches simples à des agents utilisant des modèles moins coûteux.
Le rôle d’orchestrateur demande de comprendre l’ensemble : repérer les dépendances, donner des missions précises et examiner les résultats avant de les réunir. Solo décrit ce fonctionnement avec un agent principal et des agents exécutants. Workflow d’orchestration
Dans notre exemple, le modèle le plus capable pourrait analyser le problème d’export et fixer les critères d’acceptation. Un modèle économique pourrait ensuite adapter un libellé, documenter un filtre ou ajouter un cas de test précisément décrit dans une structure existante.
Pour que cette répartition soit utile, chaque mission doit indiquer son objectif, les fichiers autorisés, ce qu’il ne faut pas modifier et la manière de vérifier le résultat. Il faut aussi avoir évalué le modèle sur ce type de travail : une petite tâche peut cacher une difficulté importante.
On réserve ainsi le modèle coûteux aux étapes qui justifient ses capacités. Son raisonnement et son contexte peuvent consommer beaucoup de tokens ; cela ne signifie pas qu’un modèle plus capable en consomme toujours davantage. La facture dépend aussi du tarif par token et du nombre de tentatives.
L’économie reste à mesurer : transmettre du contexte, coordonner les agents et corriger leurs erreurs a aussi un coût. Si une mission devient ambiguë ou dépasse les capacités de l’exécutant, elle doit revenir à l’orchestrateur. Pour une correction minuscule, un seul agent peut rester le meilleur choix.
Si tu hésites encore, commence par une seule tâche que tu sais évaluer. Si tu utilises déjà plusieurs agents, demande-toi surtout où tu perds le fil : les consignes, les dépendances ou le suivi des résultats.
Pour en savoir plus, visite le site de Solo et teste l’application sur un projet connu. Observe si elle t’aide réellement à organiser le travail et à garder la maîtrise des changements. Je reviendrai sur cet outil dans un article dédié.
Aller vite ne suffit pas
Je ne crois pas qu’il faille opposer les développeurs « de la vieille école » aux autres. Une équipe a besoin de gens qui savent avancer et de gens qui savent reconnaître les problèmes avant qu’ils arrivent en production. Souvent, ce sont les mêmes.
L’IA donne une possibilité supplémentaire d’explorer et de produire. Elle ne transforme pas automatiquement une première version en solution fiable.
La mesure utile reste le temps nécessaire pour obtenir quelque chose que l’on peut comprendre, vérifier et maintenir. Pas le nombre de lignes générées.
Tu peux essayer sans renoncer à tes exigences
Le scepticisme devient utile lorsqu’il produit une expérience sérieuse : une tâche limitée, des critères clairs et un bilan honnête.
Il devient moins utile lorsqu’il nous empêche de regarder un outil parce que nous avons peur de l’étiquette qui l’accompagne.
Tu n’as rien à prouver en tapant personnellement chaque ligne. En revanche, tu as une responsabilité envers ce que tu livres.
Apprends l’outil. Garde ton jugement. Et laisse les résultats, plutôt que les étiquettes, décider de la place qu’il mérite dans ton travail.