L'agent intelligent AI, la clé pour augmenter la taille de l'entreprise de cent fois

Écrire : vas

Traduction : AididiaoJP, Foresight News

L’IA n’est pas de la magie, mais elle n’est pas non plus aussi simple que « monter un programme d’IA, tout automatiser, attendre les bénéfices ». La plupart des gens ne savent en réalité pas ce qu’est vraiment l’IA.

Et ceux qui comprennent réellement (moins de 5%) essaient de la construire eux-mêmes, mais échouent souvent. Les agents intelligents peuvent avoir des « hallucinations », oublier à mi-chemin où ils en sont dans une tâche, ou faire des appels incorrects d’outils au mauvais moment. Lors des démonstrations, ils fonctionnent parfaitement, mais en environnement de production, ils s’effondrent immédiatement.

Je déploie des programmes d’IA depuis plus d’un an. Ma carrière dans le logiciel a commencé chez Meta, mais il y a six mois, j’ai quitté mon poste pour créer une entreprise spécialisée dans le déploiement d’agents IA opérationnels pour les entreprises. Aujourd’hui, notre revenu annuel récurrent atteint 3 millions de dollars, et continue de croître. Ce n’est pas parce que nous sommes plus intelligents que les autres, mais parce que nous avons expérimenté, échoué plusieurs fois, et finalement compris la formule du succès.

Voici tout ce que j’ai appris dans la construction d’agents réellement utilisables. Que vous soyez débutant, expert, ou quelque part entre les deux, ces expériences devraient vous être utiles.

Première leçon : le contexte, c’est tout

Cela peut sembler évident, peut-être en avez-vous déjà entendu parler. Mais c’est si important qu’il faut le répéter encore et encore. Beaucoup pensent que construire un agent intelligent consiste simplement à connecter différents outils : choisir un modèle, ouvrir l’accès à une base de données, et c’est tout. Cette approche échouera immédiatement pour plusieurs raisons :

L’agent ne sait pas ce qui est important. Il ignore ce qui s’est passé cinq étapes auparavant, ne voit que l’étape en cours, et devine ce qu’il doit faire ensuite (souvent à tort), en croisant les doigts.

Le contexte, c’est souvent la différence fondamentale entre un agent valant des millions et un agent sans valeur. Il faut se concentrer et optimiser ces aspects :

Ce que l’agent se souvient : pas seulement la tâche en cours, mais aussi tout l’historique qui a conduit à la situation actuelle. Par exemple, lors du traitement d’une anomalie de facture, l’agent doit connaître : comment l’anomalie a été déclenchée, qui a soumis la facture initiale, quelle politique s’applique, comment le fournisseur a été traité lors du dernier problème. Sans cet historique, l’agent ne fait que deviner, ce qui est pire que de ne pas avoir d’agent du tout. Car si un humain gère le problème, il aurait probablement déjà résolu la situation. Cela explique aussi pourquoi certains râlent : « L’IA, c’est vraiment difficile à utiliser ».

Comment l’information circule : lorsque vous avez plusieurs agents, ou un seul agent qui gère plusieurs étapes, l’information doit être transmise avec précision entre chaque étape, sans perte, corruption ou mauvaise interprétation. L’agent chargé de classifier la requête doit transmettre un contexte propre et structuré à celui qui résout le problème. Si la transition est bâclée, tout devient chaotique. Cela implique que chaque étape doit avoir une entrée et une sortie structurées et vérifiables. Par exemple, la fonction /compact dans Claude Code permet de transmettre le contexte entre différentes sessions LLM.

La connaissance du domaine métier par l’agent : un agent chargé de la révision de contrats juridiques doit connaître quels clauses sont clés, quelles sont les évaluations de risque, quelles sont les politiques internes de l’entreprise. On ne peut pas simplement lui donner une pile de documents en espérant qu’il en déduira l’essentiel. C’est votre responsabilité. Et cela inclut aussi : fournir des ressources structurées pour que l’agent possède une vraie connaissance du domaine.

Une mauvaise gestion du contexte se manifeste par : l’agent qui répète l’appel à un même outil parce qu’il a oublié qu’il a déjà obtenu la réponse ; ou qui appelle le mauvais outil suite à une mauvaise information ; ou qui prend des décisions contradictoires avec les étapes précédentes ; ou qui traite chaque tâche comme totalement nouvelle, ignorant les motifs évidents dans des tâches similaires antérieures.

Une bonne gestion du contexte permet à l’agent de fonctionner comme un expert expérimenté : il établit des liens entre différentes informations sans que vous ayez besoin de lui expliquer explicitement leur relation.

Le contexte, c’est la clé pour différencier un agent « juste démonstratif » d’un agent « réellement opérationnel en production et livrant des résultats ».

Deuxième leçon : l’agent IA est un multiplicateur de résultats

Idée fausse : « Avec ça, on n’a plus besoin d’embaucher. »

Idée correcte : « Avec ça, trois personnes peuvent faire le travail qui nécessitait auparavant quinze. »

L’agent finira par remplacer une partie du travail humain, il ne faut pas le nier. Mais l’aspect positif, c’est que l’agent ne remplacera pas le jugement humain, il éliminera plutôt les frictions liées à ce jugement : recherche d’informations, collecte de données, croisement, mise en forme, distribution des tâches, rappels, etc.

Par exemple : l’équipe financière doit toujours prendre des décisions en cas d’anomalie, mais avec l’agent, elle n’a plus à passer 70% de la semaine de clôture à chercher des documents manquants. Elle peut utiliser ce temps pour résoudre réellement le problème. L’agent effectue tout le travail de base, l’humain ne fait que la validation finale. D’après mon expérience avec mes clients, en réalité, cela ne conduit pas à des licenciements. Les employés voient leur travail évoluer, passant de tâches fastidieuses manuelles à des activités à plus forte valeur ajoutée, du moins pour l’instant. Bien sûr, à long terme, avec l’évolution de l’IA, cette situation pourrait changer.

Les entreprises qui tirent réellement parti des agents ne sont pas celles qui veulent simplement exclure l’humain du processus, mais celles qui comprennent que la majorité du temps des employés est consacrée à des « tâches préparatoires » plutôt qu’à la création de valeur réelle.

En concevant votre agent selon cette logique, vous n’aurez plus besoin de vous focaliser sur la « précision » : l’agent fait ce qu’il sait faire, l’humain se concentre sur ce qu’il sait faire.

Cela permet aussi un déploiement plus rapide. Il n’est pas nécessaire que l’agent gère toutes les situations extrêmes, mais qu’il traite bien les cas courants, et qu’il transfère les anomalies complexes à l’humain, avec suffisamment de contexte pour une résolution rapide. Au moins, c’est la démarche recommandée à l’heure actuelle.

Troisième leçon : mémoire et gestion d’état

La façon dont l’agent conserve l’information dans une tâche et entre plusieurs tâches détermine sa capacité à évoluer à grande échelle.

Il existe généralement trois modes :

Agent indépendant : gère un flux de travail complet de A à Z. Le plus simple à mettre en place, car tout le contexte est centralisé. Mais à mesure que le processus s’allonge, la gestion de l’état devient un défi : l’agent doit se rappeler des décisions prises à la troisième étape, pour les réutiliser à la dixième. Si la fenêtre de contexte est saturée ou si la structure de mémoire est inadéquate, les décisions ultérieures manqueront d’informations clés, entraînant des erreurs.

Agent parallèle : traite simultanément différentes parties d’un même problème. Plus rapide, mais introduit des problèmes de coordination : comment fusionner les résultats ? Que faire si deux agents donnent des conclusions contradictoires ? Il faut définir des protocoles clairs pour agréger l’information et résoudre les conflits. Souvent, il faut faire intervenir un « arbitre » (humain ou un autre LLM) pour gérer ces conflits ou conditions de course.

Agent collaboratif : transfert le travail en séquence. L’agent A classe, puis transmet à B pour recherche, puis à C pour exécution. Ce mode convient pour des workflows avec des phases bien définies, mais la transition est la partie la plus fragile. Ce que l’agent A apprend doit être transmis dans un format que l’agent B peut utiliser directement.

La majorité des erreurs vient de considérer ces modes comme des « solutions techniques » alors qu’en réalité, ce sont des choix d’architecture qui déterminent directement la capacité de votre agent.

Par exemple, si vous souhaitez construire un agent pour l’approbation de contrats de vente, vous devez décider : faire gérer tout le processus par un seul agent, ou concevoir un agent de routage qui répartit la tâche entre des agents spécialisés en tarification, juridique, approbation par la direction, etc. La compréhension du processus métier réel doit guider cette décision. Et j’espère que vous pourrez transmettre ces processus à vos agents.

Comment choisir ? En fonction de la complexité de chaque étape, de la quantité de contexte à transmettre entre phases, et si ces phases doivent collaborer en temps réel ou en séquence.

Une mauvaise architecture peut vous faire perdre plusieurs mois à déboguer des problèmes qui ne sont pas des bugs, mais une inadéquation entre votre conception, votre problématique et votre solution.

Quatrième leçon : intercepter activement les anomalies, plutôt que de faire un rapport après coup

Lorsqu’on construit un système IA, la première réaction de beaucoup est : faire un tableau de bord, afficher l’information, montrer ce qui se passe. S’il vous plaît, ne faites plus ça.

Les tableaux de bord sont inutiles.

Votre équipe financière sait déjà qu’il manque des factures, l’équipe commerciale sait que certains contrats sont bloqués chez le juridique.

L’agent doit intervenir dès que le problème survient, le bloquer, et le transmettre à la personne concernée pour résolution, en lui fournissant toutes les informations nécessaires, et en agissant immédiatement.

Une facture avec des documents manquants ? Ne vous contentez pas de le noter dans un rapport. Marquez-le, identifiez qui doit compléter quoi, et transmettez le problème avec tout le contexte (fournisseur, montant, politique applicable, ce qui manque précisément). Bloquez aussi la comptabilisation de cette facture jusqu’à résolution. Cette étape est cruciale, sinon le problème se répandra dans l’organisation, et il sera trop tard pour agir.

Une approbation de contrat qui dépasse 24 heures sans réponse ? Ne pas attendre la réunion hebdomadaire. Automatiser la remontée, avec les détails de la transaction, pour que le décideur puisse trancher rapidement sans fouiller dans tous les systèmes. Il faut instaurer un sens de l’urgence.

Un fournisseur qui ne respecte pas les jalons ? Ne pas attendre qu’on le découvre. Déclencher automatiquement un plan d’urgence, et lancer le processus de réponse avant que le problème ne devienne critique.

Votre rôle d’agent IA est : faire en sorte que le problème ne puisse pas être ignoré, et que sa résolution soit extrêmement simple.

Il faut exposer directement le problème, pas le faire passer par un tableau de bord qui ne fait que le masquer.

C’est exactement l’inverse de la façon dont la majorité des entreprises utilisent l’IA : elles l’utilisent pour « voir » les problèmes, alors que vous devriez utiliser l’IA pour « forcer » leur résolution, et rapidement. Quand le taux de résolution des problèmes approche 100 %, alors seulement envisagez de faire un tableau de bord pour la visualisation.

Cinquième leçon : l’économie entre l’IA et le SaaS généraliste

Les entreprises achètent constamment des outils SaaS inutilisés pour une raison simple.

Le SaaS est facile à acheter : démonstration, devis, coche dans la liste de besoins. Si quelqu’un valide, on pense que le projet avance (même si ce n’est pas toujours le cas).

Le pire avec l’achat d’un SaaS IA, c’est qu’il reste souvent là, inactif. Il n’est pas intégré dans le flux de travail réel, devient juste un autre système à se connecter. Vous êtes contraint de migrer des données, et un mois plus tard, c’est juste un fournisseur supplémentaire à gérer. Après 12 mois, il est abandonné, mais vous ne pouvez pas vous en débarrasser, car le coût de changement est trop élevé, ce qui crée une « dette technique ».

Une IA construite sur vos systèmes existants évite ce problème.

Elle fonctionne dans vos outils actuels, sans créer de nouvelle plateforme de travail, et accélère même l’exécution des tâches. L’agent traite la tâche, l’humain ne regarde que le résultat.

Le vrai coût n’est pas « développement vs licence », mais une logique plus simple :

Le SaaS accumule une « dette technique » : chaque nouvel outil acheté ajoute une intégration à maintenir, un système qui deviendra obsolète, un fournisseur susceptible d’être racheté, transformé ou fermé.

L’agent auto-construit accumule des « capacités » : chaque amélioration rend le système plus intelligent, chaque nouveau workflow étend les possibilités. L’investissement croît en capital composé, et ne se déprécie pas avec le temps.

C’est pourquoi, depuis un an, je dis que le SaaS IA généraliste n’a pas d’avenir. Les données du secteur le confirment : la majorité des entreprises qui achètent des SaaS IA arrêtent leur utilisation en 6 mois, sans voir d’amélioration de productivité. Les véritables bénéficiaires de l’IA sont celles qui disposent d’agents personnalisés, qu’ils développent eux-mêmes ou qu’ils font développer par des tiers.

C’est pour cela que les entreprises qui maîtrisent l’agent dès le début ont un avantage structurel à long terme : elles construisent une infrastructure de plus en plus puissante. Les autres ne font que louer des outils qu’ils devront tôt ou tard remplacer. Dans un secteur en constante évolution, chaque semaine perdue est une perte majeure pour votre roadmap produit et votre business global.

Sixième leçon : déployer rapidement

Si votre projet d’agent IA met un an à être opérationnel, c’est déjà perdu.

Les plans ne suivent pas le changement. Votre flux de travail conçu ne correspond probablement pas à la réalité, et les cas marginaux que vous n’avez pas anticipés sont souvent les plus critiques. Dans 12 mois, le domaine de l’IA pourrait avoir complètement changé, et votre solution sera dépassée.

Vous devez mettre en production en 3 mois maximum.

Dans cette ère d’explosion d’informations, la vraie compétence consiste à : savoir exploiter efficacement l’information, collaborer avec elle plutôt que de la contrarier. Travailler concrètement : traiter des tâches réelles, prendre des décisions concrètes, laisser des traces traçables.

Le problème le plus courant que j’ai vu : les équipes internes sous-estiment la durée nécessaire pour un projet IA, passant de 3 mois à 6–12 mois. Ou pire — en disant 3 mois, puis en reportant sans cesse pour cause d’« imprévus ». Ce n’est pas entièrement leur faute, le domaine de l’IA est complexe.

Vous avez besoin d’ingénieurs qui comprennent vraiment l’IA : comment elle peut évoluer à grande échelle, quels problèmes rencontrent les scénarios réels, quelles sont ses capacités et ses limites. Aujourd’hui, trop de développeurs pensent que l’IA peut tout faire — c’est une erreur. Si vous souhaitez entrer dans le domaine de l’IA d’entreprise, vous devez maîtriser ses limites concrètes.

En résumé

Pour construire un agent utilisable, l’essentiel est :

Le contexte, c’est tout : un agent sans bon contexte n’est qu’un générateur de nombres aléatoires coûteux. Assurez-vous que la circulation de l’information, la mémoire persistante et l’intégration du domaine soient solides. Autrefois, on riait des « prompt engineers », aujourd’hui, le « contexte engineer » est sa version 2.0.

Concevoir pour « augmenter » plutôt que « remplacer » : faire faire aux humains ce qu’ils savent faire, et utiliser l’agent pour dégager la voie, afin qu’ils se concentrent sur ce qu’ils font de mieux.

L’architecture est plus importante que le choix du modèle : décider entre agents indépendants, parallèles ou collaboratifs, c’est une décision d’architecture qui détermine la capacité de votre système. Mettez-la en place correctement dès le départ.

Intercepter et résoudre, plutôt que de faire des rapports ou des revues : un tableau de bord est la « tombe » du problème. Il faut construire un système qui pousse à une résolution rapide.

Lancer rapidement, itérer en continu : le meilleur agent est celui qui est déjà en production et s’améliore constamment, pas celui encore en conception. (Et suivre votre calendrier de près.)

Les autres détails sont secondaires.

La technologie est prête, mais vous ne l’êtes peut-être pas encore.

Comprendre cela, c’est pouvoir multiplier votre échelle d’affaires par 100.