Qu'est-ce qu'un agent IA ?

La plupart des pages qui vendent un agent le présentent comme un produit indivisible : vous l'achetez, ou vous ne l'achetez pas. C'est commode pour vendre et trompeur pour décider, parce qu'un agent n'est pas un bloc. C'est un assemblage de trois choses séparables.

Le harness est le programme qui fait tourner la boucle. Il contient le prompt système, la gestion du contexte, les garde-fous, l'aiguillage vers les outils, la reprise sur erreur.

Le modèle est le LLM. C'est la couche dont tout le monde parle, et la seule qui se remplace vraiment.

Les outils et les skills sont ce que l'agent peut faire et ce qu'il sait faire. Deux choses différentes, on y revient.

Retenez la conséquence avant le détail : la couche la plus commentée est la plus interchangeable, et les deux autres sont celles qui vous appartiennent.

Une démo d'agent tient en un prompt. Un agent en production tient dans le harness, et c'est la partie que les démos ne montrent jamais.

Ce qu'il faut y écrire, concrètement :

• Le prompt système — le rôle, les limites, le ton, ce que l'agent n'a pas le droit de faire.
• La boucle — quand appeler un outil, quand s'arrêter, combien de tours avant d'abandonner.
• La gestion du contexte — une conversation longue dépasse la fenêtre du modèle. Il faut résumer, élaguer, décider quoi garder. Fait naïvement, l'agent oublie l'essentiel et retient le bavardage.
• Les garde-fous — ce qui est vérifié avant qu'une action parte, et ce qui déclenche une validation humaine.
• La reprise sur erreur — une API qui tombe, un outil qui renvoie autre chose que prévu, un modèle qui invente un argument. En production, ça arrive tous les jours.

C'est du logiciel, pas du prompt. Et c'est réutilisable : le même harness sert plusieurs agents. C'est aussi la raison pour laquelle « il suffit d'un abonnement » n'est pas une réponse complète — l'abonnement vous donne le modèle, pas la boucle.

Claude, GPT, Gemini, un modèle à poids ouverts derrière un agent comme Hermes. Ils ne se valent pas sur tout, mais ils font le même travail dans l'architecture : ils raisonnent et décident quel outil appeler.

Deux précisions honnêtes, parce que l'inverse se lit partout.

Changer de modèle est le changement le moins coûteux — pas un changement gratuit. Les prompts se retouchent, la fiabilité de l'appel d'outil varie d'un modèle à l'autre, les fenêtres de contexte diffèrent. Comptez des jours, pas des mois. À comparer avec la reconstruction d'outils, qui se compte en semaines.

Aucun assistant généraliste n'embarque la téléphonie. Transformer un agent en standard téléphonique demande un opérateur, de la transcription, de la synthèse vocale, et un budget de latence qui décide si le résultat est utilisable ou pénible. Ce n'est pas une faiblesse du modèle : c'est une couche d'interface, et elle demande de l'infrastructure.

Un outil est une fonction que le modèle peut appeler : lire un agenda, créer une facture, interroger une base. C'est déterministe — l'agent fait quelque chose.

Une skill est une procédure écrite, chargée quand elle sert : comment se rédige un devis chez vous, dans quel ordre, avec quelles mentions. Ce n'est pas exécutable — l'agent sait comment faire.

Les confondre coûte cher, parce qu'on essaie alors de coder ce qui devrait s'écrire, ou d'écrire ce qui devrait s'exécuter.

MCP, et pourquoi ça change la donne

Le Model Context Protocol est la manière standard de brancher un outil à un agent. Les principaux agents l'ont adopté, et la conséquence est simple à énoncer : un outil écrit une fois fonctionne avec le modèle suivant et avec le harness suivant.

Vous passez de Claude à ChatGPT, ou à un modèle ouvert que vous hébergez : vos outils viennent avec vous. Seul le harness se réajuste, et il est fait pour ça.

C'est ce qui rend cohérente une position qui pourrait sembler contradictoire : dire « ne dépendez pas d'un fournisseur » tout en travaillant avec des modèles commerciaux. Nous ne vendons pas un modèle. Nous construisons des outils qui survivent au modèle.

Trois couches suffisent à décrire un agent. Il en faut trois de plus pour qu'il tienne en production.

La mémoire et la connaissance. Le court terme est la fenêtre de contexte. Le moyen terme, des fichiers de travail. Le long terme, une base ou un index. Ce n'est pas du harness : ça persiste entre les sessions, et c'est votre actif. Celui qui détient la mémoire détient la valeur.

L'interface. Comment on atteint l'agent : un chat, Slack, un e-mail, le téléphone, une tâche planifiée, une API. Le même agent derrière deux interfaces différentes est deux produits différents pour l'utilisateur — et c'est là que se situe vraiment la question de la voix.

La gouvernance. Avec quelles identifiants l'agent agit, ce qu'il a le droit de faire, ce qui reste tracé, comment on sait qu'il fonctionne encore. C'est ce qui sépare une démo d'un système, et c'est la question à poser avant de signer : qui détient les accès ?

Il n'y a pas de bonne réponse générale. Il y a une grille.

Acheter gagne quand le besoin est standard, quand il faut que ça tourne cette semaine, et surtout quand la solution embarque une infrastructure que vous n'avez pas — la téléphonie en premier. Un produit packagé a déjà résolu des problèmes que vous n'avez pas envie de résoudre.

Construire gagne quand le processus est le vôtre et pas celui du secteur, quand les données ne doivent pas sortir, et quand l'horizon dépasse deux ans. À trois ans, un abonnement par poste finit souvent par coûter plus que ce qu'on aurait payé une fois.

La grille cache une troisième option, qui est la plus fréquente en pratique : acheter le socle et construire ce qui vous distingue. Vous prenez un modèle sur abonnement, et vous investissez dans les outils et le harness — les deux couches qui restent à vous quand le reste change.

Comparez des totaux, pas des prix d'appel.

Côté produit packagé : l'abonnement par utilisateur et par mois, le paramétrage initial, les connecteurs facturés en supplément, et le coût de sortie — combien de temps pour reprendre vos données et vos processus le jour où vous partez.

Côté construit : la conception, le développement des outils, l'abonnement au modèle qui reste dû, l'hébergement, et la maintenance. Le budget est plus lourd au départ et plus plat ensuite.

Le chiffre que presque personne ne calcule est le coût de sortie. Il ne se voit pas la première année et décide de tout la troisième.

Sans nous, et sans budget.

1. Choisissez une tâche répétitive et ennuyeuse que quelqu'un fait à la main plusieurs fois par semaine. Pas la plus stratégique : la plus régulière.
2. Écrivez la procédure comme si vous l'expliquiez à une nouvelle recrue. Si vous n'y arrivez pas, aucun agent n'y arrivera non plus — et vous venez d'apprendre quelque chose d'utile.
3. Faites-la à la main avec un assistant, en copier-coller, pendant une semaine. Vous verrez où ça bloque avant d'avoir écrit une ligne de code.
4. Listez les outils qu'il faudrait brancher pour supprimer le copier-coller. Cette liste est votre cahier des charges.

Ces quatre étapes coûtent quelques heures et évitent des projets entiers.