Trois choses différentes. Un seul mot dans le catalogue.

Série « Comprendre l’IA », note 3 sur 12. Les deux premières expliquaient ce qu’est l’intelligence artificielle et comment un modèle de langage travaille de l’intérieur. Celle-ci sort de la machine et entre dans la salle de réunion.

Mardi, 9 h 30, la grande salle d’une entreprise de logistique à Genève. Trois fournisseurs, trois présentations, un même mot sur les trois couvertures. Le premier montre un système qui lit les commandes dans les courriels et les saisit dans le logiciel de gestion. Le deuxième, un « robot » qui copie des données d’un écran à l’autre sans que personne ne touche la souris. Le troisième, un « agent » qui répond tout seul aux clients. Les trois disent intelligence artificielle. Les trois coûtent plus cher que le nouveau camion. Et la propriétaire, qui distingue depuis trente ans un bon transporteur d’un mauvais en cinq minutes, se rend compte qu’elle ne sait pas par où commencer la comparaison.

La scène est imaginaire. La confusion, non. Elle naît parce que trois technologies séparées par soixante ans ont été rangées sous le même mot, et parce que cela arrange celui qui vend. Dans cette note, je vous donne les trois définitions, une image pour ne pas les oublier, un critère pour savoir laquelle il vous faut dans chaque cas et les sept questions que j’utilise pour démonter une présentation en une demi-heure. À la fin, la prochaine fois que quelqu’un vous dira « c’est de l’IA », vous saurez exactement ce qu’il vous dit. Et ce qu’il ne vous dit pas.

Le logiciel suit des règles. Le robot de processus imite des mains. Le modèle prédit. Les trois automatisent, mais un seul peut se tromper avec élégance.

Premièrement : le logiciel, ou les règles écrites.

Un programme classique est une recette. Quelqu’un a écrit, pas à pas, ce qu’il faut faire de chaque donnée : si la facture dépasse 10 000 francs, demande une seconde signature ; si le client est en Italie, applique cette taxe ; si le champ est vide, affiche une erreur. Chaque règle a été pensée par une personne et écrite par une autre, ou la même. Le programme ne comprend rien. Il exécute.

Cela a une vertu énorme que nous tenons souvent pour acquise : il est déterministe. Avec les mêmes données d’entrée, il produit toujours la même sortie. S’il échoue, il échoue toujours de la même manière, et quelqu’un peut lire la règle et la corriger. Votre logiciel de comptabilité, votre système de réservation et la feuille de calcul avec laquelle vous calculez vos marges sont des logiciels en ce sens. Ils automatisent depuis des décennies, et bien. La majeure partie de ce qu’une entreprise doit automatiser reste, en 2026, du logiciel de toujours. Il vaut la peine de s’en souvenir avant la deuxième présentation.

Sa limite est tout aussi claire. Il ne fait que ce que quelqu’un a su écrire comme règle. Et il y a des choses que personne ne sait écrire comme règle : reconnaître qu’un courriel est une réclamation même s’il ne contient pas le mot réclamation, résumer un contrat, décider quelle commande est urgente en lisant le ton du client. Là, le logiciel classique s’arrête.

Deuxièmement : l’automatisation robotisée des processus, ou les mains qui imitent.

À la fin des années 2000 est apparue une idée simple et très rentable. Beaucoup d’entreprises ont des programmes qui ne se parlent pas : celui des commandes n’est pas relié à la facturation, la banque n’est pas reliée à la comptabilité. Quelqu’un, chaque matin, copie des données d’un écran à l’autre. Et si un programme imitait cette personne ? Il ouvre l’application, clique où elle clique, copie ce qu’elle copie, colle où elle colle. On a appelé cela l’automatisation robotisée des processus, RPA selon le sigle anglais. Le « robot » n’est pas une machine : c’est un programme qui bouge la souris et tape au clavier.

IBM la définit avec une distinction qui vaut de l’or en réunion. La RPA est pilotée par le processus : elle suit des flux définis, pas à pas, et travaille avec des données structurées, celles qui sont déjà dans des champs et des colonnes. L’intelligence artificielle est pilotée par les données : elle apprend des motifs et peut travailler avec des données non structurées, comme du texte libre, des images ou de la voix. Elles sont complémentaires, dit IBM, et c’est vrai. Mais ce n’est pas la même chose, et un robot de processus est, au fond, du logiciel classique avec une autre interface : aussi déterministe et aussi aveugle que n’importe quelle recette.

L’image que j’utilise est celle d’une cuisine. Le logiciel, c’est la recette. Le robot de processus, c’est un commis qui suit la recette à la lettre, ouvre les tiroirs et appuie sur les boutons du four, mais ne goûte pas la sauce. Il est très utile tant que la cuisine ne change pas : si quelqu’un déplace le tiroir des couteaux, le commis ouvre le vide. C’est pour cela que les projets de RPA cassent chaque fois qu’un fournisseur change la disposition d’un écran. Si on vous a vendu un robot qui « s’adapte » aux changements d’écrans, demandez comment. La réponse est presque toujours : avec une personne qui le répare.

Troisièmement : l’intelligence artificielle, ou le cuisinier qui goûte la sauce.

La troisième technologie est celle que nous avons expliquée dans les deux notes précédentes. Un modèle entraîné sur d’énormes quantités d’exemples qui, au lieu de suivre des règles écrites, prédit : le mot suivant, la catégorie d’un courriel, le contenu d’un champ à partir d’un PDF scanné. Personne ne lui a écrit la règle « ceci est une réclamation ». Il a vu des millions de réclamations et en reconnaît une nouvelle même si elle est rédigée avec une courtoisie toute suisse.

Dans la cuisine, c’est le cuisinier. Il goûte la sauce, remarque qu’il manque du sel et corrige. Il peut improviser avec ce qu’il y a dans le réfrigérateur. Et il peut se tromper : confondre le sucre et le sel avec la même assurance que lorsqu’il a raison le reste du temps. C’est la différence décisive avec les deux autres technologies et la raison de toute cette série. Le logiciel et le robot échouent de façon prévisible. Le modèle échoue de façon plausible. Une règle mal écrite produit une erreur visible ; un modèle mal configuré produit une réponse qui a l’air correcte.

De là vient la question qui m’a le plus rapporté en réunion, et que je vous offre : « Si je l’exécute deux fois avec les mêmes données, est-ce qu’il sort exactement la même chose ? » Si la réponse est oui, on vous vend du logiciel ou un robot de processus, quoi qu’en dise la couverture. Si la réponse est « presque », on vous vend un modèle, et à partir de ce moment toutes les autres questions doivent porter sur la manière de mesurer et de contrôler ce « presque ».

Lequel il vous faut, et quand.

Ce n’est pas une compétition. Presque tous les bons projets que j’ai vus combinent les trois, et l’erreur habituelle est de mettre un modèle là où une règle suffisait, ou une règle là où il fallait un modèle. Mon critère tient dans un tableau mental à deux questions : les règles sont-elles claires ? et les données sont-elles ordonnées ?

• Règles claires, données ordonnées. Logiciel. Une formule, une validation, un flux d’approbation. C’est le moins cher, le plus fiable et ce qui demande le moins de surveillance. Exemple : signaler une facture échue depuis 30 jours.
• Règles claires, données ordonnées, programmes qui ne se parlent pas. Robot de processus, le temps de construire la vraie connexion. Exemple : passer chaque matin les mouvements bancaires dans le logiciel de comptabilité. Sachez que c’est une béquille, pas une solution, et qu’elle cassera au prochain changement d’écran.
• Règles floues ou données non structurées. Modèle d’IA. Exemple : lire les courriels qui arrivent sur info@, décider de quoi ils traitent, extraire la commande et proposer une réponse. Là, il y a vraiment quelque chose qu’aucune règle ne savait faire.
• Jugement avec conséquences. Un modèle qui propose et une personne qui décide. Exemple : classer les réclamations par gravité. La machine trie la boîte de réception ; la décision d’indemniser est signée par quelqu’un.

Observez que, dans les deux derniers cas, le modèle travaille rarement seul. En général, il lit quelque chose de désordonné, le transforme en données ordonnées et les remet au logiciel de toujours, qui applique les règles à partir de là. L’IA ordonne ; le logiciel exécute ; le robot, s’il le faut, bouge la souris. Quand un fournisseur vous montre un système, demandez-lui de vous indiquer sur le schéma où se trouve chacune des trois pièces. S’il ne sait pas, ce n’est pas lui qui l’a construit.

Le mot le plus usé du catalogue : agent.

Reste le quatrième mot, celui de la troisième présentation. En 2026, presque tout s’appelle agent. Il vaut la peine de savoir d’où il vient et ce qu’il y a derrière.

Anthropic a publié en décembre 2024 un guide technique pour ceux qui construisent ces systèmes, et y trace une ligne qui vous servira : un flux de travail est un système où le modèle et les outils sont orchestrés selon des chemins définis à l’avance dans le code ; un agent est un système où le modèle décide lui-même des étapes à suivre et des outils à utiliser pour accomplir une tâche. Le même guide ajoute deux conseils qu’un vendeur répète rarement : cherchez toujours la solution la plus simple possible, et n’utilisez des agents que pour des problèmes ouverts où l’on ne peut pas prédire le nombre d’étapes. Pour presque tout le reste, dit-il, un seul appel au modèle bien fait suffit. Je consacre la note 5 à cette distinction.

Le marché a pris une autre direction. Le 25 juin 2025, Gartner a publié une prévision qui devrait être affichée dans toutes les salles d’achats : plus de 40 % des projets d’agents d’IA seront annulés avant fin 2027, pour cause de coûts croissants, de valeur peu claire ou de contrôles des risques insuffisants. Dans la même note, Gartner a forgé un terme, « agent washing », pour décrire la pratique consistant à rebaptiser agents des produits qui n’en sont pas : assistants, robots de processus, automatisations classiques avec une nouvelle couche de peinture. Gartner estimait que, parmi les milliers de fournisseurs qui disaient vendre des agents, seuls environ 130 étaient réels. Et dans une enquête auprès de 3412 dirigeants, 19 % avaient fait des investissements importants dans les agents, 42 % des investissements prudents, 8 % aucun et 31 % attendaient de voir.

Je ne vous raconte pas cela pour que vous n’achetiez pas d’agents. Je vous les expliquerai, et bien, dans deux notes. Je vous le raconte pour que, lorsque vous entendrez le mot, vous posiez la question de tout à l’heure : est-ce le modèle qui décide des étapes, ou un programmeur ? La plupart du temps, c’est un programmeur, et c’est une bonne nouvelle, parce que c’est moins cher, plus prévisible et plus facile à contrôler. Ce n’est une mauvaise nouvelle que si vous l’avez payé au prix d’autre chose.

Sept questions pour une demi-heure.

Je les pose dans cet ordre, et la qualité des réponses m’en dit plus que la démonstration.

• Si je l’exécute deux fois avec les mêmes données, est-ce que la même chose sort ? Sépare le logiciel du modèle. Elle vient en premier parce qu’elle change toutes les autres.
• Quelle partie est modèle, quelle partie est règle et quelle partie est robot ? Demandez qu’on vous le montre sur un schéma. Celui qui l’a construit le sait par cœur.
• Quel modèle, de qui et en quelle version ? Si la réponse est « notre propre moteur d’IA », insistez. En 2026, presque personne n’entraîne son propre modèle ; presque tous utilisent celui d’un grand fournisseur. C’est légitime, mais cela change qui contrôle le prix et les changements.
• Avec quels cinquante cas à moi le mesure-t-on ? Pas les siens. Cinquante courriels, factures ou appels réels de votre entreprise, avec la bonne réponse connue. Si ce n’est pas possible, ce n’est pas évaluable.
• Que se passe-t-il quand il ne sait pas ? La bonne réponse est : il le dit et passe la main à une personne. La mauvaise : il répond toujours.
• Qu’est-ce qui casse quand quelque chose change ? Un écran, un format de facture, la version du modèle. Qui le répare, en combien de temps et à quel prix.
• Où vont mes données ? Chez quel fournisseur, dans quel pays, si elles servent à l’entraînement et comment elles sont effacées. Nous le traiterons calmement dans la note sur les données et la loi, mais la question se pose dès la première réunion.

1. Cette semaine, 30 minutes

   Faites l’inventaire des trois pièces

   Listez les programmes que vous avez déjà et marquez chacun : recette, commis ou cuisinier. Vous découvrirez que presque tout est recette, et que cela fonctionne.

2. À la prochaine présentation

   Posez la question des deux exécutions

   Avant de voir la démonstration. Observez si le vendeur la comprend du premier coup.

3. Avant de demander un prix

   Demandez le schéma avec les trois pièces indiquées

   Et qu’on vous dise à qui appartient le modèle et en quelle version. Gardez la réponse par écrit.

4. Avant de signer

   Préparez vos cinquante cas

   Réels, avec la bonne réponse à côté. C’est votre jeu de référence, et il sert à comparer les trois fournisseurs avec la même mesure.

Comment je l’aborde.

Dans mes projets, la première semaine, on n’écrit pas de code : on dessine le schéma avec les trois pièces. Il y a presque toujours plus de recette que le client ne l’attendait et moins de modèle qu’on ne lui en avait vendu. Le modèle est réservé à ce qu’aucune règle ne sait faire, il est mesuré avec les cinquante cas avant d’être allumé et on lui donne la permission de dire « je ne sais pas ». Le reste est du logiciel, et le logiciel, quand il est bien fait, n’a pas besoin d’étiquette.

Avant la prochaine note, pensez à la dernière proposition d’« IA » arrivée sur votre bureau. Rayez mentalement ce mot et demandez-vous ce qui reste : une règle qu’on pourrait écrire, un robot qui imite des clics ou un modèle qui doit vraiment comprendre quelque chose ?

Si vous ne savez pas dans quelle case elle tomberait, ce n’est pas un défaut de votre part. C’est exactement la question à laquelle la proposition aurait dû répondre pour vous. Et il vaut peut-être la peine de se demander pourquoi elle ne l’a pas fait.

Note suivante : la carte. Ce qu’un modèle de langage sait faire aujourd’hui dans une entreprise, service par service, avec ce que les études ont réellement mesuré et ce qui reste une promesse.