Une automatisation fiable se prouve, elle ne se croit pas sur parole. Donc voici deux histoires de la semaine, vécues chez nous, pas chez un client. En fait, on les raconte parce qu’elles montrent exactement ce qu’est une automatisation fiable, et ce qu’elle n’est pas.

Le réglage qui n’existait pas

D’abord, sur notre propre site, un réglage important. On le croyait actif depuis des jours : l’interface l’affichait comme fait. Mais un script de vérification est allé regarder la page réelle, telle que le monde la voit. Résultat, rien : le réglage n’était appliqué nulle part. Ainsi, l’interface disait oui, le site disait non.

Combien de temps on aurait mis à s’en apercevoir sans vérification ? Aucune idée, et c’est exactement ça, le problème.

Le rapport qui disait « réussi »

Ensuite, deuxième histoire. Une tâche automatique tourne, le rapport affiche un succès. Sauf que la tâche avait planté. En fait, le message de succès venait de la dernière étape de la chaîne, une étape d’affichage, pas de celle qui faisait le vrai travail. Donc le voyant vert était branché sur le mauvais fil.

Or, ces deux pannes ont un point commun : zéro bruit. Pas de message d’erreur, pas d’alerte, juste un système qui te laisse croire que tout va bien.

Journal de vérification qui prouve une automatisation fiable après un test d'échec provoqué

Une automatisation fiable se prouve, elle ne se croit pas

La plupart des outils du marché échouent en silence. Un message qui ne part pas, un formulaire qui n’enregistre pas : personne n’est prévenu. Voici donc ce qui fait une automatisation fiable, ce qu’on exige de chaque système qu’on livre :

  • D’abord, une preuve visible. Tu vois que ça a tourné, sans avoir à demander : un journal, une notification, une ligne quelque part.
  • Ensuite, une alerte quand ça casse. En effet, le silence n’est pas une preuve de bon fonctionnement, c’est une absence d’information.
  • Puis zéro perte. Si une étape échoue, la demande du client n’est pas perdue : elle est mise de côté et rejouée. D’ailleurs, le principe rejoint l’idempotence en informatique : rejouer une action ne doit jamais la dupliquer.
  • Enfin, une vérification de l’état réel. On ne croit pas l’interface, on regarde plutôt ce que reçoit vraiment le client, ce qu’affiche vraiment la page.

Casse ton détecteur avant de lui faire confiance

Enfin, dernier réflexe, le moins connu : quand tu mets en place une vérification, commence par la faire échouer exprès. Ensuite, débranche quelque chose, envoie un cas cassé, et regarde si ton alarme sonne. En effet, une alarme qu’on n’a jamais entendue sonner ne protège rien.

C’est l’équivalent du test d’évacuation : tu ne veux pas découvrir le jour de l’incendie que la sonnerie ne marchait pas. Résultat, c’est exactement ce qui distingue une automatisation fiable d’un système qui a simplement eu de la chance jusqu’ici.

Chez toi : une automatisation fiable ou un pari ?

Donc cette semaine, choisis une automatisation dont tu dépends, une seule, et pose la question : si elle s’arrêtait ce soir, qui le saurait, et quand ? Si la réponse est « personne, avant qu’un client se plaigne », alors tu n’as pas une automatisation fiable, tu as un pari.

Et avant même la fiabilité, il y a le choix de quoi automatiser : l’erreur numéro un quand on automatise un processus reste la plus coûteuse. Pour un audit de tes systèmes, écris-nous.

Qu’est-ce qui rend une automatisation fiable ?

Une preuve visible que ça a tourné, une alerte quand ça casse, zéro perte de données en cas d’échec, et une vérification de l’état réel plutôt que de l’interface.

Comment tester si une automatisation fiable alerte vraiment en cas de panne ?

En la faisant échouer exprès. Débranche quelque chose, envoie un cas cassé, et regarde si l’alarme sonne. En effet, une alarme jamais entendue ne protège rien.

Que faire si une étape échoue dans le système ?

La demande du client ne doit jamais être perdue : elle est mise de côté et rejouée automatiquement. C’est la base d’une automatisation fiable, même en cas de panne partielle.

Edouard Vilver, cofondateur de Meriaky

À propos de l’auteur

Edouard Vilver · Cofondateur de Meriaky

Ingénieur en informatique, 15 ans d’expérience, dont plus de 7 ans à la Banque Nationale du Canada. Il y a mis en place la signature électronique et migré des systèmes vers le cloud. Aujourd’hui, il aide les PME à automatiser leur suivi client et leurs tâches répétitives grâce à l’IA.

Son profil LinkedIn