L'IA agentique en pratique : 2 heures de préparation, 3 jours d'exécution

Quand on parle d'IA agentique, l'image qui vient spontanément est celle d'un développeur qui tape un prompt et qui regarde l'IA coder à sa place. C'est à la fois vrai et profondément trompeur. Vrai parce que oui, l'agent finit par écrire le code. Trompeur parce que le prompt de 30 secondes qui produit du code médiocre et le prompt de 2 heures qui produit un résultat parfait n'ont absolument rien en commun — sauf le mot "prompt".

La réalité que j'observe sur le terrain est contre-intuitive : les meilleurs résultats avec l'IA agentique viennent des gens qui passent le plus de temps à ne pas coder. La préparation, le cadrage, la formulation du contexte — c'est ça le vrai travail. Le code qui en sort n'est que la concrétisation d'une réflexion déjà aboutie.

Le malentendu fondamental

La plupart des tentatives échouent parce qu'elles partent d'un malentendu : l'IA agentique accélère l'écriture du code. En réalité, elle accélère la transformation d'une idée claire en code fonctionnel. La nuance est fondamentale.

Si votre idée est floue — "fais-moi un système de notifications" — le résultat sera flou. L'agent va produire quelque chose de générique, qui ne correspond pas à vos contraintes, et vous passerez plus de temps à corriger qu'à avoir écrit le code vous-même. C'est exactement ce qui se passe dans les tests rapides qui concluent que "l'IA ne marche pas".

En revanche, si votre idée est précise — si vous avez passé du temps à définir le contexte technique, les contraintes métier, les cas limites, les conventions à respecter et le résultat attendu — l'agent produit un résultat d'une qualité qui surprend même les développeurs les plus sceptiques. Parce que l'agent ne devine plus ce que vous voulez : il exécute ce que vous lui avez clairement décrit.

Le basculement mental est celui-ci : la valeur n'est plus dans l'écriture du code, elle est dans la qualité de la réflexion qui le précède. Et ça change tout — pour les développeurs, pour les managers, et pour l'organisation entière.

Histoire 1 : construire un CRM de A à Z

J'ai récemment construit mon propre CRM — gestion des prospects, pipeline commercial, devis, contrats, time tracking. Un outil complet avec une API Symfony, un frontend Next.js et une base MongoDB. Le genre de projet qui occupe habituellement une petite équipe pendant plusieurs mois.

Voici comment ça s'est réellement passé.

Je n'ai pas commencé par dire à Claude Code "fais-moi un CRM". J'ai commencé par écrire. Un prompt de plusieurs dizaines de lignes qui décrivait mon contexte : freelance en CTO/CPO fractionnel, besoin de suivre des prospects, de créer des devis, de tracker mon temps par client. J'ai détaillé les fonctionnalités attendues, les choix techniques que je souhaitais (Symfony pour l'API parce que c'est mon expertise, Next.js pour le frontend, MongoDB parce que la flexibilité du schéma convenait au stade de maturité du projet).

Puis j'ai demandé à Claude de challenger mon approche. Pas de coder — de challenger. "Est-ce que cette architecture tient la route ? Qu'est-ce que je n'ai pas prévu ? Quels sont les pièges classiques d'un CRM maison ?" Cette phase de dialogue a duré environ une heure. Claude a soulevé des questions auxquelles je n'avais pas pensé — la gestion des brouillons de devis, la génération de PDF avec signature électronique, le système d'invitation pour que mes clients puissent accéder à leurs devis en ligne.

Ce n'est qu'après cette heure de préparation et de challenge mutuel que le code a commencé à s'écrire. Et là, effectivement, c'est allé vite. Les fondations étaient claires, les conventions documentées, les cas limites identifiés. L'agent savait exactement quoi faire parce que le travail de conception avait été fait en amont.

Le résultat : un CRM fonctionnel en production, avec envoi de devis par email, suivi du pipeline, gestion des contrats, time tracking et tableau de bord. Le genre de projet qui aurait représenté 3 à 6 mois de développement pour une personne seule. Pas parce que l'IA "code plus vite" — parce que l'IA transforme une heure de réflexion structurée en des jours de code correct.

Histoire 2 : les notifications push chez Winter

L'exemple le plus parlant que j'ai observé récemment vient d'un développeur chez Winter, une startup GreenTech que j'accompagne. Le sujet : mettre en place un système de notifications push sur mobile qui devait suivre un scénario précis pour améliorer le taux de retour des utilisateurs. Ce n'est pas un sujet trivial — c'est un sujet produit autant que technique, avec des implications sur l'engagement, la rétention et l'expérience utilisateur.

Le développeur aurait pu foncer dans le code. C'est ce qu'on aurait fait il y a un an. Au lieu de ça, il a passé 1 à 2 heures en préparation avec les parties prenantes — le product owner, le marketing, moi — pour bien cerner les attendus. Quels scénarios de notification ? À quel moment ? Avec quelles règles de fréquence pour ne pas spammer ? Comment mesurer l'impact sur le returning ?

Ensuite, il a passé 1 à 2 heures supplémentaires avec Claude Code. Pas à coder — à expliquer le contexte. À décrire l'architecture existante de l'application. À détailler les scénarios de notification, les contraintes techniques (push iOS vs Android, gestion du consentement, queuing), les règles métier. Claude l'a challengé en retour : "et si l'utilisateur désactive les notifications puis les réactive, quel est le comportement attendu ?", "comment gérez-vous les fuseaux horaires ?", "avez-vous pensé au mode avion et à la réception différée ?".

Ce dialogue de préparation a fait émerger des cas limites que personne n'avait anticipés dans le cadrage initial. C'est un point que les sceptiques de l'IA ne voient jamais : l'agent ne se contente pas d'exécuter — il challenge. Il pose des questions que vos développeurs n'osent pas toujours poser parce qu'ils ne veulent pas avoir l'air de "pas savoir" ou de "ralentir le projet".

Seulement après ces 2 à 4 heures de préparation (cadrage + contexte Claude), l'implémentation a commencé. Résultat : ce qui aurait pris plusieurs sprints — probablement 3 à 4 semaines en comptant les allers-retours de code review, les corrections de bugs et les ajustements de scénarios — a été livré en 2 à 3 jours. Avec une couverture de tests supérieure à ce qu'on aurait eu en "mode classique" parce que les cas limites avaient été identifiés en amont, pas découverts en production.

Le pattern commun : la préparation EST le travail

Ces deux histoires partagent le même schéma :

Phase	Durée	Activité
Préparation	1-2 heures	Cadrage du besoin, contraintes, cas limites
Contexte IA	1-2 heures	Explication à l'agent, challenge mutuel
Implémentation	1-3 jours	L'agent code, le développeur valide
Total	2-3 jours	Au lieu de 3-6 semaines

Le ratio est frappant : 2 à 4 heures de préparation produisent 2 à 4 semaines d'économie. C'est un retour sur investissement de l'ordre de 1 pour 30 sur le temps passé.

Ce pattern inverse complètement la répartition du temps d'un développeur. Dans le modèle classique, un développeur passe peut-être 20% de son temps à réfléchir et 80% à coder. Avec l'IA agentique, cette répartition s'inverse : 60 à 80% du temps est consacré à la préparation, au cadrage et à la validation, et 20 à 40% à piloter l'exécution. Le code produit est meilleur parce que la réflexion qui le précède est meilleure.

Ce que ça change pour les managers

Si vous managez une équipe technique, cette inversion a des implications profondes.

Le "bon développeur" se redéfinit. Ce n'est plus celui qui code le plus vite — c'est celui qui pose les meilleures questions, qui anticipe les cas limites et qui formule les instructions les plus claires. Les compétences de communication, d'analyse et de pensée systémique deviennent plus valorisées que la vitesse d'écriture.

Les rituels changent. Le pair programming évolue vers le "pair prompting" — deux personnes qui réfléchissent ensemble à la meilleure manière de formuler un problème avant de laisser l'agent l'implémenter. Les code reviews portent moins sur le style du code et plus sur la pertinence des décisions architecturales.

L'estimation change. "Combien de temps pour cette feature ?" n'a plus la même réponse. Ce qui prenait 3 sprints prend peut-être 3 jours — mais seulement si les 2-4 heures de préparation sont faites sérieusement. Si vous court-circuitez la préparation pour "aller plus vite", vous retrouvez les résultats médiocres qui alimentent le rejet de l'IA. La préparation n'est pas un luxe — c'est le prérequis du résultat.

Votre rôle évolue aussi. En tant que manager ou dirigeant, vous passez de "donner des tickets à exécuter" à "donner du contexte à transformer". Plus vous fournissez de contexte business à vos développeurs — la vraie raison derrière la feature, les contraintes des utilisateurs, les objectifs de l'entreprise — plus l'IA produit un résultat aligné avec ce qui crée de la valeur.

C'est peut-être le changement le plus profond : l'IA agentique récompense les organisations qui communiquent bien. Celles où le business et la tech se parlent, où le contexte circule, où les décisions sont documentées. Et elle pénalise celles où les silos empêchent l'information de circuler — parce que sans contexte, même le meilleur agent produit du code générique.