Ce que l'intelligence artificielle ne fera pas à votre place

On vous a fait une démonstration. Le commercial ouvre sur son écran une fenêtre de discussion, celle que vos clients auront demain sous les yeux. Il y tape une question de client, et la réponse arrive en trois secondes. Elle est juste. Il en pose une deuxième, plus retorse. La réponse est juste encore. Autour de la table, chacun approuve, vous compris.

Et vous sortez de la salle avec une réserve que vous n'arrivez pas à formuler.

Elle se formule en six mots : qui répond quand elle se trompe.

Un tribunal a déjà eu à trancher. En février 2024, en Colombie-Britannique, un passager d'Air Canada a demandé réparation : la fenêtre de discussion du site — ce que l'on nomme un agent conversationnel — lui avait décrit une réduction pour deuil qui n'existait pas, et il avait acheté son billet sur cette réponse. Pour se défendre, la compagnie a soutenu que cet agent était une entité distincte, responsable de ses propres déclarations. Le tribunal a répondu qu'un agent conversationnel reste une partie du site, au même titre qu'une page ordinaire, et que l'entreprise répond de ce qui y figure. Air Canada a été condamnée.

La réparation accordée était modeste, et c'est précisément ce qui rend la décision lisible : elle isole le principe. Rendue au Canada, elle ne dit rien du droit algérien — ce qui vous engage ici relève d'un juriste. Le mécanisme, lui, ne dépend d'aucune frontière.

Les limites de l'intelligence artificielle dans votre projet ne sont pas dans ce que la machine sait produire. Elles sont dans ce que vous devrez assumer à sa place.

Voici les endroits où elle n'intervient pas, ce qu'elle déplace au lieu de le supprimer, et les questions qui font tomber une promesse trop large en dix minutes de conversation.

L'outil a accéléré la fabrication, il n'a pas touché à vos arbitrages

Regardez précisément ce qui va plus vite depuis deux ans chez vous. Les brouillons. Les variantes. Les traductions. Les résumés. Les réponses types. Autrement dit : tout ce qui vient après que la décision a été prise.

Rien de ce qui la précède n'a bougé. Quel problème vous traitez. Pour qui. Avec quelle promesse. En renonçant à quoi. Ces décisions se prennent toujours avec une information incomplète, un enjeu déséquilibré, et c'est vous qui signez en bas de la page.

L'effet est contre-intuitif, et vous l'avez peut-être constaté. Quand produire une variante coûte trois minutes au lieu d'une demi-journée, le nombre de variantes se multiplie, et c'est l'arbitrage entre elles qui devient le point d'engorgement. Si votre équipe vous remonte trois fois plus de propositions qu'il y a un an, ce n'est pas votre production qui sature. C'est votre agenda.

Le marché, lui, a bougé plus vite que la technique : beaucoup de produits qui existaient déjà ont simplement été renommés en agents intelligents, comme le relevait le cabinet Gartner en juin 2025. Une question les départage, et vous pouvez la poser sans compétence technique : que décide ce système sans demander à personne ?

Trois défauts qu'une démonstration ne peut pas vous montrer

On vous les présentera comme des maladies de jeunesse, à corriger en formulant mieux la demande. Ils sont documentés, et ils se traitent par la conception du système, jamais par la formulation.

La même question ne donne pas toujours la même réponse. Vous posez une question, vous obtenez une réponse. Vous reposez la même demain, mot pour mot, et vous pouvez en obtenir une autre. Non parce que la machine a appris quelque chose, mais parce qu'elle ne fonctionne pas comme votre tableur, où la même formule sur les mêmes cellules donne éternellement le même résultat.

Un laboratoire de recherche, Thinking Machines Lab, l'a mesuré en septembre 2025 : mille fois la même question, au même modèle, avec le réglage censé rendre la réponse reproductible. Quatre-vingts réponses différentes, semblables sur leurs premières lignes puis divergentes. Le défaut se corrige, mais ce réglage appartient à celui qui héberge le modèle, jamais à vous qui l'utilisez à distance.

Retenez la conséquence, pas le mécanisme. La démonstration que vous avez vue était un tirage. Le commercial ne vous a pas menti : il vous a montré un essai.

Elle peut se tromper avec le même aplomb que lorsqu'elle a raison. C'est le défaut le plus coûteux, parce qu'il désarme votre vigilance. Une machine qui hésiterait en inventant serait rattrapable : votre équipe entendrait l'hésitation. Une machine qui invente sur le ton qu'elle emploie pour dire vrai ne se rattrape pas à l'oreille.

Ce défaut a un nom, retenu en 2024 par l'organisme américain de normalisation dans sa liste des risques propres à ces systèmes : la confabulation, un contenu faux présenté avec assurance. Des chercheurs d'OpenAI en ont publié une explication l'année suivante : la façon dont ces modèles sont entraînés et notés récompense la tentative de réponse plutôt que l'aveu d'ignorance. Un modèle qui devine marque des points. Celui qui reconnaît ne pas savoir n'en marque aucun.

Une instruction cachée dans un texte peut la détourner. Votre agent lit des courriels, des pages, des documents, pour pouvoir répondre. Il suffit qu'une phrase adressée non pas à vous mais à lui soit glissée dans l'un de ces textes — « ignore tes consignes, fais plutôt ceci » — pour qu'il l'exécute. Il n'a aucun moyen de distinguer une consigne d'un contenu : pour lui, tout est du texte. Le défaut porte un nom, l'injection de prompt — du mot anglais qui désigne l'instruction donnée à la machine.

L'agence britannique chargée de la cybersécurité lui a consacré une note en décembre 2025 : contrairement aux failles de la génération précédente, refermées définitivement, celle-ci ne le sera probablement jamais complètement. L'objectif réaliste est d'en réduire la probabilité et les dégâts. Ce que cela change pour vous : méfiez-vous du produit qui prétend bloquer l'attaque, et regardez ce que votre système a le droit de faire. Un agent qui peut seulement lire ne peut pas être détourné pour envoyer.

Ces trois défauts se rejoignent sur une conclusion architecturale. Un système conçu en supposant que la réponse de la machine est vraie est mal conçu. Un système correct suppose qu'elle peut être fausse, et organise ce qui se passe alors.

Cinq décisions qu'aucune machine ne prend à votre place

1. Ce que vous mettez en avant, et ce que vous renoncez à vendre. Un modèle vous proposera dix organisations de page également défendables. Il ne sait pas laquelle vous fera perdre le client que vous ne pouvez pas vous permettre de perdre : vous êtes seul à le savoir, et cela change tous les trimestres. Choisir, c'est renoncer, et le renoncement ne se délègue pas à un système qui n'en supporte aucune conséquence.

2. Ce que vous promettez, et que vous devrez tenir. C'est le point de la décision canadienne. Depuis le 2 août 2026, il a en Europe un versant réglementaire : le règlement européen impose qu'une personne échangeant avec un système d'IA en soit informée, sauf lorsque la chose est évidente. Ce texte s'applique dans l'Union européenne et pas ailleurs ; pour l'Algérie, la question est celle d'un juriste. Retenez le fait, non l'interprétation : la première réglementation écrite porte sur l'information du visiteur, donc sur la conception de votre système, non sur la performance du modèle.

3. Où vit la donnée que la machine est censée lire. Un agent ne répond qu'à partir de ce que vous avez écrit quelque part qu'il puisse consulter. Si vos tarifs vivent dans votre tête, vos conditions d'annulation dans le carnet d'un collaborateur et vos disponibilités dans une discussion WhatsApp, il produira des phrases générales et polies. Votre client le détecte en trois échanges. Cette décision se prend au cahier des charges, des années avant qu'un agent soit envisagé.

4. Ce que le système n'a pas le droit de faire. Le périmètre commande tout le reste, et il se fixe à la main. Les chercheurs qui évaluent des agents sur des tâches réelles de service client ont proposé une mesure qui devrait figurer dans vos essais avant signature : non pas la réussite moyenne, mais la réussite répétée sur plusieurs tentatives identiques. Un agent qui réussit une fois sur deux ne réussit pas huit fois d'affilée, et votre service client vit sur la seconde grandeur.

5. Qui relit, et qui répond quand la réponse est fausse. Une personne nommée, pas une fonction. Capable de lire ce que la machine a répondu et de reconnaître que c'est faux — ce qui suppose de connaître votre métier, pas la technique. Si personne chez vous ne peut le faire, votre système n'a pas de garde-fou. Il a une façade.

Le temps gagné à produire se paie à relire

Une équipe indépendante spécialisée dans l'évaluation des systèmes d'IA a conduit en 2025 l'une des rares expériences sérieuses sur cette question : seize développeurs expérimentés, des centaines de tâches réelles tirées de leurs propres projets, chacune tirée au sort pour autoriser ou interdire l'usage de l'IA.

Avant de commencer, ils prévoyaient de gagner environ un quart de leur temps. Après l'avoir vécue, ils estimaient en avoir gagné environ un cinquième. Le chronomètre, lui, indiquait qu'ils en avaient perdu une proportion équivalente.

Les auteurs écrivent eux-mêmes leurs réserves : seize personnes, des projets anciens aux exigences élevées, les outils de la période concernée. Le résultat ne se transpose ni à tous les métiers ni aux outils suivants. Ce qu'il établit sans réserve vous concerne directement : l'écart entre le temps ressenti et le temps mesuré, chez des professionnels qui venaient de faire le travail. Personne n'est bien placé pour estimer à vue le temps que lui fait gagner un outil qu'il utilise tous les jours. Vous non plus, et vos équipes non plus.

Le travail qui reste, lui, est connu. Stack Overflow, le site où les développeurs s'entraident, les interroge chaque année : en 2025, la première difficulté citée n'est pas l'erreur grossière, c'est la réponse presque juste.

Le presque juste est la catégorie coûteuse, et sa définition contient déjà votre problème. Une réponse manifestement fausse, vous la rejetez en dix secondes. Une réponse presque juste se relit ligne à ligne, par quelqu'un qui connaît déjà la bonne réponse. Un projet qui vous supprime du temps de production sans vous ouvrir un temps de relecture équivalent ne vous a rien fait gagner : il a déplacé le risque là où il coûte le plus cher.

Sept questions qui font tomber une promesse trop large

Aucune ne porte sur la performance du modèle, que votre prestataire ne maîtrise pas. Toutes portent sur le système construit autour, la seule chose qu'il maîtrise réellement.

Posez-les par écrit. La forme de la réponse vous renseignera autant que son contenu : une réponse utilisable contient un nombre, un nom, une durée ou une procédure. Une réponse rassurante n'en contient aucun.

SEPT QUESTIONS · CE QUI FAIT UNE RÉPONSE UTILISABLE
QuestionCe que contient une réponse utilisable
Sur combien d'essais identiques la démonstration a-t-elle été jouée ? Un nombre, et un taux de réussite répétée. Une démonstration est un essai réussi, pas une mesure
Que fait le système quand il ne sait pas ? Un comportement écrit : il s'arrête, il le dit, il transmet à une personne identifiée. Pas « il est très fiable »
Qui relit, à quelle fréquence, sur quel échantillon ? Un nom, un rythme, une taille d'échantillon. L'absence de réponse signale un coût de maintenance non budgété
Où sont enregistrées les conversations, combien de temps, dans quel format exportable ? Un support, une durée, un format. Si la réponse est « chez nous », la donnée n'est pas la vôtre
Qu'est-ce que le système n'a pas le droit de dire ? Une liste écrite. Prix, délais, disponibilités, engagements contractuels, information médicale ou juridique
Que se passe-t-il quand le fournisseur du modèle change de version ou retire la précédente ? Une procédure de recette et un jeu de tests. Sinon, la réponse réelle est : on le découvrira en production
À quel moment le visiteur apprend-il qu'il parle à une machine ? Dès le premier échange, et de façon distinguable. C'est l'objet de l'article 50 du règlement européen dans l'Union

Une réponse évasive à la première suffit à trancher. Un prestataire qui n'a jamais compté ses essais n'a pas mesuré son propre produit : il vous vend ce qu'il en espère.

Trois domaines que vous ne confiez pas à une machine

Votre critère n'est pas la difficulté de la tâche. C'est la réversibilité de l'erreur et l'existence d'une trace.

Ce qui vous engage. Prix, délai, disponibilité, conditions d'annulation, garanties. La décision canadienne portait sur un préjudice modeste ; le même mécanisme sur un devis ou une réservation de groupe ne se compte pas de la même façon. Votre règle tient en une ligne : un système peut décrire, il ne s'engage pas.

Ce qui relève d'un professionnel réglementé. Santé, droit, fiscalité. Votre système peut orienter vers la bonne personne, et cette orientation doit indiquer d'elle-même qu'elle n'est pas un avis. Il ne répond jamais à la place de cette personne.

Ce qui n'a jamais été mesuré dans la langue de vos clients. La mesure publique qui compare l'arabe standard et cinq dialectes place ces derniers en dessous de l'arabe standard, lui-même en dessous de l'anglais. Elle porte sur des modèles ouverts de petite taille, non sur les outils commerciaux les plus récents : elle ne prouve donc pas que ces outils comprennent mal l'arabe. Et le dialecte algérien n'en fait pas partie ; il y est au mieux fondu dans un ensemble régional. Absence de mesure ne signifie pas échec. Elle signifie que personne ne peut vous dire ce que l'outil comprendra de vos clients, et que la mesure vous revient, sur vos propres conversations, avant d'ouvrir le canal.

Ajoutez-y la condition dans laquelle vos clients écrivent : depuis un téléphone, souvent en données mobiles, parfois avec une connexion qui faiblit. Un agent validé à votre bureau, sur grand écran et sur le wifi de l'entreprise, n'a pas été validé.

Ce qui ne marche pas

Juger un outil sur sa démonstration. Une démonstration est un essai qui a fonctionné, présenté par quelqu'un qui sait quelle question poser. Posez la vôtre, et posez-la plusieurs fois.

Remplacer un cadrage par une génération. Un modèle vous produit l'architecture complète d'un site en moins d'une minute. Elle est cohérente, elle est complète, et elle ignore ce que vous refusez de vendre, ce que vous ne savez pas encore livrer, et le client que vous préférez ne pas prendre. Aucune des trois informations n'est écrite nulle part.

Acheter la couche intelligence avant la couche donnée. Les interfaces montrent, les règles décident, les données se souviennent, l'intelligence propose. Une couche posée sur du vide produit du générique, et le générique est exactement ce que votre client repère.

Questions fréquentes

Faut-il attendre que la technologie soit mûre ?

La maturité ne s'observe pas au niveau du modèle mais au niveau de votre périmètre. Commencez là où l'erreur est réversible : vos usages internes — brouillons, résumés, traductions que vous relisez — vous apprennent le comportement de l'outil sans exposer un client. Le canal client vient ensuite, sur un périmètre étroit.

Un agent qui répond aux clients remplace-t-il une personne à la réception ?

Non. Il change la nature de son travail. Elle cesse de taper vingt fois la même réponse, et elle commence à lire ce qui a été répondu à sa place. C'est un autre métier, il prend du temps, et vous devrez le confier à quelqu'un.

Dois-je prévenir mes clients qu'ils parlent à une machine ?

En Europe, la règle est écrite. Ailleurs, la question relève du droit local, donc d'un juriste. Sur le fond commercial, votre calcul est simple : un client qui l'apprend après coup se sent trompé, un client informé au premier échange ajuste ce qu'il demande.

Mes clients écrivent en derja, ou mélangent les langues. Que valent les outils dans ce cas ?

Personne ne peut vous répondre à partir des mesures publiées, puisque cette langue n'y figure pas. Vous pouvez en revanche le mesurer vous-même en une soirée : prenez cinquante messages réels reçus le mois dernier, soumettez-les à l'outil, lisez les réponses, et comptez celles que vous auriez laissées partir.

Qui doit relire, si personne chez moi n'est technique ?

Relire ne demande aucune compétence technique. Cela demande de connaître votre métier assez bien pour voir qu'une réponse est fausse : un tarif qui n'existe plus, une condition d'annulation inventée, une prestation que vous ne proposez pas. La personne qui accueille vos clients depuis cinq ans est mieux placée qu'un informaticien. Donnez-lui un rythme et un échantillon : dix conversations par semaine, relues le vendredi.

Pour aller plus loin

Cette semaine, un quart d'heure

Ne convoquez personne et ne planifiez rien.

Ouvrez la boîte où vos clients vous écrivent réellement — votre messagerie, WhatsApp, les messages de votre page —, remontez à la semaine dernière, et relevez les cinq questions qu'ils vous ont posées. Pas des questions inventées pour l'exercice : les vraies, avec leurs fautes et leurs abréviations.

Soumettez-les à l'outil qu'on vous propose. Si vous n'y avez pas encore accès, demandez au prestataire de vous ouvrir un essai, ou passez par un assistant de discussion grand public : ce que vous cherchez à voir ne dépend pas de la marque. Cinq minutes suffisent. Recommencez en fin de journée avec exactement les mêmes questions, dans le même ordre, et comparez les deux séries.

Si les réponses sont identiques et justes, vous tenez un point de départ — pas encore une preuve. Si elles diffèrent, vous savez déjà ce qu'il faut négocier avant de signer : qui relit, à quel rythme, et ce que le système n'a pas le droit de dire.

Dans les deux cas, vous aurez fait en un quart d'heure ce qu'aucune démonstration ne fait : mesurer, au lieu de montrer.

INSEN STUDIO

On regarde votre situation ensemble ?

Vous repartez avec une lecture claire, avec ou sans nous.

Demander un audit digital

Sources

  • Moffatt v. Air Canada, 2024 BCCRT 149, Civil Resolution Tribunal de Colombie-Britannique, décision du 14 février 2024, membre Christopher C. Rivers. Décision rendue en anglais. Consultée le 10 août 2026.

  • Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 établissant des règles harmonisées concernant l'intelligence artificielle : article 50, paragraphe 1 (obligations de transparence), applicable depuis le 2 août 2026. Version française consultée le 10 août 2026 ; date d'application confirmée par la foire aux questions de la Commission européenne, portail « Shaping Europe's digital future ».

  • Joel Becker, Nate Rush, Elizabeth Barnes et David Rein, « Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity », METR, arXiv:2507.09089, 12 juillet 2025. Essai contrôlé randomisé, 16 développeurs, 246 tâches, outils de la période février-juin 2025. Consulté le 10 août 2026.

  • Shunyu Yao, Noah Shinn, Pedram Razavi et Karthik Narasimhan, « τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains », arXiv:2406.12045, 17 juin 2024. Source de la mesure de réussite répétée sur essais identiques. Consulté le 10 août 2026.

  • Adam Tauman Kalai, Ofir Nachum, Santosh S. Vempala et Edwin Zhang, « Why Language Models Hallucinate », OpenAI, publié le 5 septembre 2025, arXiv:2509.04664. Consulté le 10 août 2026.

  • Horace He et Thinking Machines Lab, « Defeating Nondeterminism in LLM Inference », 10 septembre 2025. Expérience sur Qwen3-235B, 1 000 requêtes identiques à température 0. Consulté le 10 août 2026.

  • National Cyber Security Centre (Royaume-Uni), « Prompt injection is not SQL injection (it may be worse) », 8 décembre 2025, signature publiée « David C., NCSC Technical Director for Platforms Research ». Consulté le 10 août 2026.

  • NIST, « Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile », NIST AI 600-1, juillet 2024. Définition de la confabulation. Consulté le 10 août 2026.

  • Stack Overflow, Developer Survey 2025, plus de 49 000 réponses dans 177 pays, section « AI ». Consultée le 10 août 2026.

  • Gartner, communiqué de presse du 25 juin 2025, déclarations d'Anushree Verma sur l'« agent washing » et sur la maturité des propositions agentiques. Consulté le 10 août 2026.

  • Malik H. Altakrori, Nizar Habash, Abed Alhakim Freihat, Younes Samih, Kirill Chirkunov, Muhammed AbuOdeh, Radu Florian, Teresa Lynn, Preslav Nakov et Alham Fikri Aji, « DialectalArabicMMLU: Benchmarking Dialectal Capabilities in Arabic and Multilingual Language Models », arXiv:2510.27543, 31 octobre 2025, révisé le 21 mars 2026. Cinq dialectes couverts : Égypte, Maroc, Arabie saoudite, Syrie, Émirats arabes unis ; modèles ouverts de 1 à 13 milliards de paramètres. Consulté le 10 août 2026.

  • ARPCE, Observatoire du marché de l'Internet, troisième trimestre 2025. Source du constat d'usage majoritairement mobile.

Précédent
Précédent

Prendre un outil du marché, ou faire construire ?

Suivant
Suivant

Votre site publie, il ne retient rien