Vos sécurités automatiques n'ont jamais servi. Fonctionnent-elles ?
Une sécurité automatique est une condition qui empêche une action : ne pas écrire deux fois, ne pas écrire en cas de doute, ne rien envoyer. Par nature, elle ne se déclenche presque jamais. Son silence ressemble donc exactement à son bon fonctionnement, et personne ne sait laquelle des deux situations il observe.
Qu'est-ce qu'une sécurité dans une automatisation ?
Quand on décrit un automate, on décrit ce qu'il fait. Il lit un événement, il prépare, il écrit une note dans Pipedrive, il alerte sur Slack. La partie la plus importante est pourtant celle qui l'empêche d'agir.
Sur nos agents, un seul chemin d'exécution mène à une écriture. Tous les autres mènent à un silence délibéré ou à une alerte. Ces garde-fous portent des noms simples : ne pas traiter deux fois la même transcription, ne pas écrire quand plusieurs affaires pourraient convenir, ne jamais envoyer un message à un client depuis Gmail.
Ces conditions ont une particularité gênante. Elles ne servent que dans des situations rares. Un automate qui tourne parfaitement pendant six mois n'apporte aucune preuve que ses sécurités marchent. Il apporte seulement la preuve que les situations rares ne sont pas arrivées.
Comment un garde-fou peut-il ne jamais pouvoir se déclencher ?
Voici le cas exact, trouvé sur un de nos agents n8n avant sa mise en service.
Le contrôle anti-doublon posait une question simple : cet événement a-t-il déjà été traité ? Pour y répondre, il cherchait la référence de la transcription dans les notes déjà présentes sur l'affaire Pipedrive. Le principe est bon.
Sauf que le nœud voisin, celui qui met en forme la note en HTML pour Pipedrive, n'écrivait plus cette référence. Elle avait été retirée du modèle de rédaction, pour de bonnes raisons, sans que personne ne fasse le lien.
Le contrôle cherchait donc une valeur que rien n'écrivait. Il ne trouvait jamais rien. Sa réponse était toujours la même : cet événement est nouveau, tu peux écrire.
Chaque moitié du mécanisme était correcte. La paire était cassée. Et aucun test ne portait sur la paire.
Conséquence si le même événement repassait, ce qui arrive au moindre rejeu depuis n8n : une seconde note identique sur l'affaire Pipedrive de production, un second brouillon Gmail vers le même client, et un second appel au modèle facturé. Le tout avec la mention « déjà traité » affichée les deux fois.
Pourquoi les tests ne l'avaient pas vu ?
Cet agent était pourtant couvert par plus de 250 tests automatisés. Trois raisons expliquent le trou, et elles se retrouvent partout.
On teste des moitiés. Un test vérifiait que le contrôle cherchait bien la référence. Un autre vérifiait que la note était bien rendue. Aucun ne vérifiait que les deux parlaient de la même valeur. Le défaut traversait trois maillons : la condition, le passage de l'information d'un nœud à l'autre, et l'écriture dans Pipedrive.
Ce qui est écrit à part n'est pas testé pareil. Nous avons audité l'agent en cassant volontairement ses garanties, une par une, pour voir si les tests protestaient. Sur une vingtaine de garanties rangées dans des modules, presque toutes ont fait rougir la suite de tests. Cinq autres, écrites directement dans le générateur qui produit le workflow n8n, n'avaient aucun filet. Dont celle qui empêchait le doublon.
Un test peut être vert pour une mauvaise raison. Un test qui cherche un mot dans un long texte passe presque toujours : le mot survit dans un commentaire, un libellé, un message d'alerte. Une dizaine de tests de ce chantier se sont révélés vides quand nous les avons soumis à cette épreuve, dont trois qui avaient déjà été renforcés une première fois.
C'est un des motifs pour lesquels tant de projets s'arrêtent en route. Gartner prévoit que plus de 40 % des projets d'agents seront abandonnés d'ici fin 2027, notamment par manque de maîtrise des risques. Une sécurité qu'on n'a jamais vue fonctionner n'est pas une maîtrise, c'est une intention.
Comment prouver qu'une sécurité fonctionne ?
Il n'existe qu'une méthode, et elle est à la portée de tout le monde : la casser exprès, sur une copie, et vérifier que quelque chose proteste.
C'est ce que nous faisons maintenant garantie par garantie. On retire la condition qui empêche le doublon, on relance les tests, et on regarde. Si tout reste au vert, le test qui devait la protéger ne protégeait rien. On le réécrit avant de continuer.
Deux règles en sont sorties, valables au delà de notre métier. Un test doit exiger la formulation correcte, jamais interdire une formulation fautive : il existe toujours une autre façon d'écrire la même erreur. Et celui qui vérifie doit refaire la manipulation lui-même, au lieu de lire le compte rendu de celui qui l'a faite. Sur ce chantier, un rapport affirmait de bonne foi que sept tests tombaient sous un sabotage. Il y en avait trois.
| Avant | Après |
|---|---|
| Chaque moitié du mécanisme testée séparément | Un test exige que le contrôle et l'écriture portent sur la même valeur |
| Les garanties écrites hors des modules n'ont aucun filet | Toute décision est déplacée dans une fonction testable |
| Un test vert vaut preuve | Un test n'est cru qu'après avoir échoué sur une garantie retirée |
| Le rejeu d'un événement crée une seconde note et un second message | Le rejeu ne produit rien, et le prouve sur demande |
| Le relecteur lit le rapport de l'implémenteur | Le relecteur rejoue le sabotage lui-même |
Que demander à celui qui a construit votre automate ?
Vous n'avez pas besoin de lire du code pour savoir où vous en êtes. Trois questions suffisent, et les réponses sont très parlantes.
Quelles sont les sécurités de cet automate, écrites noir sur blanc ? Laquelle s'est déjà déclenchée en conditions réelles, et que s'est-il passé ce jour là ? Et si je supprime celle qui empêche le doublon, est-ce qu'un contrôle s'en aperçoit avant la mise en service ?
Si la troisième réponse est un silence, la sécurité existe sur le papier. C'est le même raisonnement que pour un agent qui écrit dans votre CRM : le silence n'est jamais une preuve. Nous l'avions traité sous un autre angle dans votre automatisation ne s'est pas lancée ce matin. Sur des données réelles, la même exigence donne le cas un CRM, trois taux de succès. Nos engagements sont sur la page d'accueil.
Les questions qu'on nous pose
Comment vérifier qu'une sécurité automatique fonctionne ?
En la cassant volontairement sur une copie, puis en vérifiant que le contrôle proteste. Si tout reste au vert alors que la sécurité a disparu, c'est que rien ne la surveillait. Cette manipulation prend quelques minutes et elle est la seule preuve qui vaille.
Pourquoi un défaut peut-il exister alors que tout est testé ?
Parce que les tests portent souvent sur chaque moitié d'un mécanisme, jamais sur leur accord. Le contrôle cherche une référence, une autre étape est censée l'écrire. Chaque partie est correcte seule. Personne ne vérifie qu'elles parlent bien de la même valeur.
Quelles conséquences un doublon a-t-il vraiment ?
Deux notes identiques sur la même affaire Pipedrive, deux brouillons vers le même client, et un traitement facturé deux fois. Le pire reste la confiance : un commercial qui voit deux fois la même note cesse de croire ce que l'outil lui montre, et il retourne à ses notes personnelles.
Quelles questions poser à celui qui a construit votre automate ?
Trois suffisent. Quelles sont les sécurités de cet automate. Laquelle s'est déjà déclenchée en conditions réelles. Et que se passe-t-il si je supprime celle qui empêche le doublon, est-ce qu'un contrôle le voit avant la mise en service.