Pourquoi votre automatisation se trompe de fichier ou de fiche ?
Un automate se trompe de cible quand personne ne lui a dit laquelle choisir, et qu'il la déduit d'une ressemblance de texte. Le rapprochement paraît juste, il ne l'est pas, et rien ne le signale. La parade tient en une phrase : ne jamais laisser le code deviner ce qu'un humain ou un modèle peut désigner.
Qu'appelle-t-on un rapprochement automatique ?
Presque toutes les automatisations d'entreprise font la même chose à un moment : relier deux objets que personne ne leur a reliés. Un paiement et une facture. Un mail entrant et un dossier client. Un contact et son organisation dans Pipedrive ou HubSpot. Une pièce jointe et le document promis à l'oral.
Quand la donnée porte une référence commune, il n'y a pas de sujet. Le problème commence quand elle n'en porte pas. Le code doit alors rapprocher deux textes écrits par des humains différents, à des moments différents, sans convention commune. Il compare des mots, et il conclut.
Nous avons rencontré ce mur sur un agent n8n qui prépare les mails de suivi après un rendez-vous. Il lit la transcription produite par Fireflies, où le commercial dit : « je vous envoie notre grille tarifaire ». L'agent doit joindre le bon fichier, pris dans un dossier Google Drive qui en contient des dizaines. Rien ne relie la phrase au fichier.
Comment une règle simple produit quatre erreurs différentes ?
La première version cherchait les mots de la promesse dans les noms de fichiers. Elle a fonctionné, puis elle a échoué quatre fois. Chaque échec est né de la correction du précédent.
La sous-chaîne. Le mot « facture » se trouve à l'intérieur de « Manufacture ». Un document sans rapport a été joint. Correction : ne comparer que des mots entiers.
L'extension. Le commercial dit « je vous envoie le PDF ». Le mot retenu est « pdf », qui décrit tous les fichiers du dossier. Le premier de la liste part. Correction : ignorer les extensions.
Le mot générique. Le vocabulaire commercial est répétitif. « Présentation », « offre », « dossier » figurent dans la moitié des noms de fichiers du Drive. Le rapprochement se fait sur un mot qui ne distingue rien. Correction : écarter les mots trop fréquents.
Le millésime. Reste l'année. « 2026 » apparaît dans presque tous les documents à jour. Un seul candidat sort, et il est faux.
Ces quatre erreurs sont la même erreur. Une règle trouve un candidat unique, donc elle ne détecte aucune ambiguïté, donc elle n'alerte pas, et elle se trompe avec assurance.
C'est ce qui rend ce défaut si coûteux. Le garde-fou prévu, alerter quand plusieurs fichiers pourraient convenir, ne se déclenche jamais. La mauvaise règle, elle, ne trouve qu'un seul fichier. Tout paraît normal, y compris dans le journal des exécutions de n8n.
Pourquoi une liste d'exceptions ne suffira jamais ?
Après le quatrième cas, la tentation est d'ajouter une cinquième règle. C'est une impasse, et pour une raison simple : chaque règle est écrite à partir des erreurs déjà vues. Le langage humain en fabrique de nouvelles indéfiniment.
Une liste d'exceptions décrit ce qui a échoué. Elle ne prouve jamais qu'il n'existe pas d'autre voie. Tant que la conception repose sur une ressemblance de texte, il reste une cinquième erreur à découvrir, en production, sur un vrai client.
Le coût, lui, n'est pas technique. Un document envoyé à la mauvaise personne, ou un document sans rapport joint à une offre, abîme la relation en une seconde. Le temps commercial est déjà rare : selon une étude Salesforce, les vendeurs ne passent que 28 % de leur temps à vendre. Un rapprochement qu'il faut relire chaque fois annule le gain qu'on cherchait.
Que change le fait de faire désigner plutôt que deviner ?
Nous avons changé de conception. Le code ne cherche plus. Le modèle de langage reçoit la liste réelle des fichiers du Drive, avec leur identifiant, et il désigne celui qui correspond à la promesse. Le code se contente de vérifier que cet identifiant figure bien dans la liste qu'il a fournie.
Le risque ne disparaît pas, il se déplace, et c'est tout l'intérêt. Une règle qui se trompe produit un résultat faux et plausible. Un modèle qui se trompe désigne une référence qui n'existe pas, et le contrôle le voit tout de suite.
Deux précautions étaient obligatoires, et la première a failli nous échapper.
Rendre le refus possible. En supprimant l'ancienne règle, on supprime aussi le code qui refusait de choisir en cas d'ambiguïté. C'était le seul vrai garde-fou. Il a fallu le réécrire dans la consigne donnée au modèle : si plusieurs fichiers peuvent correspondre, ou si la promesse est trop vague, ne rien désigner. Sans cette phrase, le modèle n'a nulle part l'autorisation de ne pas choisir.
Vérifier ce qui manque. Une promesse oubliée ne joint rien et n'alerte pas. Il faut donc confronter deux listes : les promesses relevées dans le compte rendu, et les documents effectivement désignés. Toute promesse non couverte déclenche une alerte vers le commercial.
| Le code devine | Le modèle désigne, le code vérifie |
|---|---|
| Rapprochement par ressemblance de texte | Choix dans une liste réelle et fermée |
| Un candidat faux ressemble à un candidat juste | Une référence inventée ne correspond à rien |
| L'alerte ne part jamais, faute d'ambiguïté détectée | Le doute est une réponse autorisée et alertée |
| Chaque correction ouvre une nouvelle faille | Le nombre de cas possibles est borné par la liste |
| Une promesse oubliée passe inaperçue | Toute promesse non couverte déclenche une alerte |
| Erreur crédible, découverte par le client | Erreur visible, découverte par le contrôle |
Comment appliquer ce principe chez vous ?
Repérez les endroits où votre automatisation relie deux choses sans référence commune. Dans un scénario n8n, Make ou Zapier, ce sont ces nœuds qui produisent les erreurs silencieuses, pas les pannes.
Posez ensuite trois questions. Le rapprochement s'appuie-t-il sur une référence, ou sur une ressemblance de mots ? Existe-t-il un cas où l'automate a le droit de dire qu'il ne sait pas, et que se passe-t-il alors ? Et enfin, qui verrait le jour où il se trompe, sachant qu'un mauvais rapprochement ne produit aucune erreur technique ?
Cette exigence est la même que celle qui gouverne l'écriture d'une note dans Pipedrive : en cas de doute, ne rien écrire et prévenir. Elle est décrite dans vos commerciaux ne font pas leurs comptes rendus, et mise en oeuvre sur des données réelles dans le cas une chaîne événementielle sans ressaisie. Notre méthode complète est sur la page d'accueil.
Les questions qu'on nous pose
Pourquoi une règle de rapprochement finit toujours par se tromper ?
Parce qu'elle est écrite à partir des cas connus. Le langage humain en produit sans cesse de nouveaux. Chaque correction ferme une voie et en laisse une autre ouverte. Une liste d'exceptions ne prouve jamais qu'il n'existe pas de cinquième cas.
Un faux positif est-il détectable dans les journaux ?
Non, et c'est le vrai problème. Un mauvais rapprochement ressemble exactement à un bon : un candidat trouvé, une action réussie. Il n'y a ni erreur, ni alerte. Seul un humain qui relit le résultat s'en aperçoit, et seulement s'il connaît le dossier.
Faire désigner le résultat par une IA, n'est-ce pas plus risqué ?
Le risque change de nature, et c'est ce qui compte. Une règle qui se trompe produit un résultat faux mais plausible. Un modèle qui invente une référence désigne quelque chose qui n'existe pas, et le contrôle le voit immédiatement. Une erreur visible vaut mieux qu'une erreur crédible.
Où s'applique cette règle en dehors des pièces jointes ?
Partout où un automate relie deux choses que personne ne lui a reliées : un paiement et une facture, un mail entrant et un dossier client, un contact et son organisation dans HubSpot, un ticket et un contrat. La question est toujours la même : qui désigne, et qui vérifie.