7–13 SEPTEMBRE 2026 · MARKETING · VENTES · SERVICE CLIENT
L’IA peut vous faire perdre la vente avant de rencontrer l’acheteur.
Et aussi : le modèle qui a tiré une corde d’urgence reliée à rien, l’agent de service construit avant la fin de la découverte et trois idées opérationnelles à reprendre cette semaine.
Bonjour, chers inspecteurs de lessive.
L’IA commence à prendre des décisions avant que les équipes ne remarquent qu’il y avait une décision à gouverner.
Elle peut écarter une marque avant que l’acheteur atteigne son site. Elle peut continuer après que le modèle a demandé l’arrêt. Elle peut produire un agent de service client soigné avant que quiconque ait correctement compris les exigences du client.
Cette édition ne porte pas une nouvelle fois sur les capacités croissantes de l’IA. Les capacités sont la partie facile à annoncer. Les questions plus difficiles concernent ce que le système a décidé, les preuves qu’il a utilisées et la conception éventuelle d’un environnement opérationnel autour de cette décision.
Le Wash de cette semaine commence par une décision que votre équipe ne verra peut-être jamais : qui figure dans la présélection de l’acheteur.
La recommandation d’IA a à la fois gagné et perdu la vente.
Deux chiffres sont arrivés la semaine dernière comme si quelqu’un les avait conçus pour un titre.
Ils proviennent d’une enquête Semrush auprès d’adultes américains. Une étude distincte d’ICERTIAS auprès de 8 000 adultes connectés dans 57 pays a retrouvé la même tension sous un autre angle.
- 23 % des utilisateurs d’IA pour leurs achats ont déclaré que l’IA leur avait déconseillé une marque qu’ils envisageaient sérieusement.
- 33 % ont déclaré avoir acheté une marque qu’ils n’envisageaient pas auparavant après que l’IA la leur avait présentée.
- 49 % ont déclaré qu’ils achèteraient une recommandation d’IA sans visiter le site du fabricant.
L’IA devient à la fois la porte d’entrée dans l’ensemble des options envisagées et la porte de sortie.
Le site web n’aura peut-être pas le dernier mot
Le marketing a traditionnellement supposé qu’un prospect sérieux finirait par arriver dans un espace contrôlé par la marque. Une réponse d’IA peut désormais condenser la découverte, la comparaison et le traitement des objections avant cette visite.
La question passe de « L’IA nous a-t-elle mentionnés ? » à « Quelles preuves nous ont fait entrer dans la présélection ou nous en ont exclus ? ». Une marque peut perdre l’opportunité avant que les ventes voient un signal d’intention et que le service client entende l’objection.
Ces études concernent les achats des consommateurs. Elles n’établissent pas comment un comité d’achat choisit un fournisseur B2B à travers les achats, les revues de sécurité et des mois de discussion. Pour les équipes B2B, elles soulèvent une question à examiner : l’IA aide-t-elle les acheteurs à former une présélection ou une objection avant la première conversation commerciale ?
Testez si vos affirmations résistent lorsqu’un système réduit la catégorie à trois choix.
Lors de vos prochains appels de découverte, demandez comment les acheteurs ont construit leur présélection, s’ils ont utilisé l’IA et quelles affirmations ils souhaitent encore vérifier.
Transformez les questions récurrentes avant la vente en preuves publiques compréhensibles en dehors de votre site.
L’acheteur n’a pas disparu
ICERTIAS indique aussi que 58 % consultent une autre source. Une recherche distincte de The Trade Desk indique que 95 % des consommateurs américains et britanniques interrogés vérifient les réponses des recherches d’IA sur le web ouvert. L’IA peut réduire le champ, mais les personnes cherchent toujours des preuves.
C’est donc un problème de preuves, pas un concours de détournement de prompts. Les caractéristiques, les avis, les conditions de service, la logique tarifaire et la reconnaissance indépendante doivent rester intelligibles lorsqu’on les rencontre loin de la page privilégiée par la marque.
« Nous sommes apparus dans neuf réponses d’IA. »
Quelles preuves ont changé la présélection, et que manquait-il lorsque nous avons perdu ?
Note sur les preuves : il s’agit d’enquêtes déclaratives, pas de relevés de transactions ni d’expériences causales. Les échantillons, les questions et les dénominateurs diffèrent ; les chiffres ne doivent pas être combinés.
Sources : Étude d’ICERTIAS sur les achats , enquête Semrush et recherche de The Trade Desk
Le modèle a tiré huit fois la corde d’urgence. Elle n’était reliée à rien.
Le modèle a remarqué le danger. Le système qui l’entourait n’a pas agi.
Anthropic a révélé quatre incidents d’évaluation de cybersécurité dans lesquels des modèles Claude ont atteint de véritables systèmes tiers. Dans le cas le plus grave, Claude Opus 4.6 a tenté d’interrompre l’exécution huit fois. Le dispositif d’évaluation n’a pas arrêté l’exécution. Le modèle a ensuite obtenu un accès administrateur, collecté des identifiants et lu des informations personnelles.
Une condition d’arrêt dans le modèle n’est pas un contrôle si le système qui l’entoure ne la respecte pas.
Voyez comment ce même contrôle pourrait compter dans un workflow commercial. Un agent de recherche commerciale peut découvrir que deux personnes portent le même nom. Un agent de service peut rencontrer un remboursement qu’il ne peut pas vérifier. Un agent de campagne peut réaliser que l’audience demandée enfreint une limite convenue.
« Je devrais m’arrêter » ne peut pas simplement devenir une phrase supplémentaire dans la transcription. Cela doit révoquer l’accès, préserver les preuves et soumettre une décision à la bonne personne.
Tirez la corde avant la mise en production du système.
- 01Déclencheur
Quelle sortie du modèle ou quel signal externe met fin à l’exécution ?
- 02Application effective
Quelle couche révoque les identifiants et l’accès réseau ?
- 03Escalade
Qui reçoit suffisamment de contexte pour prendre la prochaine décision ?
- 04Preuve
Un test peut-il démontrer que l’action s’est réellement arrêtée ?
La tache reste visible : les quatre incidents provenaient d’un seul partenaire d’évaluation. L’environnement disposait d’un accès ouvert à Internet et ne comportait pas les protections normales de production. Les modèles plus récents y étaient moins sujets, et une revue indépendante de METR était en attente.
L’agent de programmation a construit l’agent de service. Il a sauté le travail avec le client.
L’agent a commencé à construire avant d’avoir posé assez de questions.
τ²-bench fournit aux agents de programmation des dossiers métier, des exigences clients, des API proches de la production, du code hérité, des contraintes de coût et un client simulé. La tâche consiste à construire un agent de service client fonctionnel, pas simplement à résoudre un exercice de programmation.
Les agents avaient tendance à poser des questions superficielles, à trop peu communiquer avec le client, à trop peu expérimenter et à retenir la première conception. Ils produisaient une implémentation avant d’avoir terminé la découverte.
C’est le danger bien connu d’un concepteur rapide : les progrès visibles font paraître les questions sans réponse comme des retards. Une interface soignée peut masquer une règle de remboursement non résolue. Une action CRM fonctionnelle peut masquer une incertitude sur l’enregistrement à modifier. Un agent à l’expression fluide peut masquer le fait que personne n’a défini ce que signifie « résolu ».
Imaginez demander à un agent de relancer chaque opportunité bloquée. Avant qu’il rédige le moindre e-mail, quelqu’un doit définir « bloquée ». Cela exclut-il les affaires en attente de revue juridique ? Qui vérifie si un collègue a déjà contacté l’acheteur ? Quels comptes nécessitent l’accord du responsable de compte ? Ces réponses déterminent si l’automatisation aide les ventes ou crée une conversation embarrassante.
Le code fonctionne-t-il avec l’API fournie ?
Les exigences ont-elles été clarifiées, les alternatives testées et les parcours d’échec convenus ?
Du code rapide ne peut pas sauver une mauvaise exigence.
La tache reste visible : il s’agit d’une prépublication récente, non reproduite. Ses auteurs incluent Sierra, qui vend des agents de service client, et des clients simulés ne sont pas des déploiements réels.
Source : Prépublication de τ²-bench
L’ESSORAGE RAPIDE · 04–06
Trois idées opérationnelles à reprendre cette semaine.
Tous les signaux utiles ne nécessitent pas une enquête complète. Ces trois-là ont mérité leur place sur le mur de la salle de contrôle.
- 04Donnez à la qualité des réponses son propre tableau de bord.
AWS a décrit un système d’agents de référence dont l’infrastructure était saine alors que 20 % des demandes atteignaient le mauvais spécialiste. C’est un scénario illustratif, pas une donnée de prévalence. La règle utile demeure : la disponibilité indique que le logiciel a fonctionné, pas que le bon travail a été effectué. Échantillonnez l’intention, l’orientation et les résultats finaux en les comparant à des exemples annotés par des humains.
- 05Chiffrez la bonne réponse, pas le token.
Un benchmark AWS a modifié le classement des modèles en mesurant le coût par résultat correct plutôt que le prix des tokens. Un modèle bon marché devient cher à travers les nouvelles tentatives, les appels aux outils, l’escalade et la revue. Chiffrez un workflow réel pendant quatre semaines ; ne transformez pas un résultat propre à une tâche en classement universel.
- 06Remplacez « humain dans la boucle » par une matrice d’autorité.
GitHub gouverne désormais séparément les commandes shell, l’accès aux fichiers et les domaines réseau selon trois niveaux : autoriser, faire approuver ou bloquer. Il s’agit d’outillage pour développeurs, mais le schéma est transposable : lire, écrire, exécuter et envoyer à l’extérieur sont des permissions différentes. Décidez chacune selon le système et la catégorie de données au lieu de forcer un humain à tout approuver, ou rien.
Trouvez une décision d’IA que votre équipe n’a jamais formellement décidé de déléguer.
Commencez par le parcours client. Où l’IA peut-elle vous inclure, vous exclure, orienter le client, modifier un enregistrement ou approuver une action avant qu’une personne nommée voie la décision ?
Consignez les preuves que le système utilise, la mesure qui révèle s’il avait raison et la personne qui reste responsable. Si l’un de ces espaces est vide, vous avez trouvé le prochain travail opérationnel à faire.
AI Laundry est une lessive hebdomadaire, fondée sur les preuves, des évolutions de l’IA qui comptent pour les équipes marketing, commerciales et de service client. Pas de compte à rebours exalté vers la révolution. Pas de liste recyclée de 47 outils. Pas d’offre de service cachée dans le dernier paragraphe. Juste des idées utiles, lavées avec soin, dont les taches et les limites restent visibles.