7 min de lecture« Ça marche » décrit un instant
Une facture arrive. Le système la lit, les informations sont extraites, le dossier est créé, un message part. La démonstration est réussie, et tout le monde sourit avec la retenue professionnelle de rigueur.
Mais demain matin, le PDF sera protégé par un mot de passe. Mardi, le fournisseur modifiera légèrement son modèle de facture. Mercredi, une API répondra au bout de trente et une secondes au lieu de trois. Jeudi, quelqu’un transférera deux fois le même email. Vendredi, étrangement, tout ira bien.
Une automatisation utilisée au quotidien ne se distingue donc pas d’une démonstration uniquement par le nombre de fois où elle tourne. Elle doit aussi savoir quoi faire quand la réalité cesse de coopérer.
Une erreur visible est généralement préférable à une réussite imaginaire
Imaginons un processus exécuté cinq cents fois par jour. Il fonctionne dans 99 % des cas, un excellent résultat. Il reste pourtant cinq anomalies par jour.
Si ces cinq opérations échouent franchement, sont enregistrées et remontent jusqu’à une personne, le système peut rester parfaitement exploitable. Si elles s’évanouissent en silence dans le néant numérique, on a affaire à un tout autre produit.
Dans ses pratiques de Site Reliability Engineering, Google rappelle que le monitoring ne sert pas seulement à produire des graphiques : il doit permettre de savoir ce qui se passe, de repérer les symptômes utiles et de déclencher une action quand elle est nécessaire. Le chapitre consacré à la surveillance des systèmes distribués insiste notamment sur la qualité des signaux et des alertes.
Une automatisation sérieuse devrait pouvoir répondre à quelques questions très ordinaires :
- A-t-elle démarré ?
- A-t-elle terminé ?
- Qu’a-t-elle fait ?
- Qu’est-ce qui a échoué ?
- Faut-il que quelqu’un intervienne ?
- Peut-on reprendre sans tout recommencer ?
Le reste est largement négociable.
Réessayer est utile. Réessayer n’importe comment produit des doublons.
Une API ne répond pas. Le réflexe, c’est de recommencer. Très bien, sauf si la première demande a bel et bien été traitée et que seule sa réponse s’est perdue en route.
Pour une simple lecture de données, ce n’est généralement pas dramatique. Pour un prélèvement, un email, une commande ou la création d’un dossier, le charme s’évapore assez vite.
C’est là qu’intervient la notion d’idempotence : on peut rejouer une même opération sans en multiplier la conséquence.
Le cadre Well-Architected d’AWS recommande justement de concevoir des interfaces idempotentes, pour qu’une requête puisse être répétée sans dupliquer l’opération. Cette pratique est présentée comme un moyen de limiter les défaillances d’interaction entre systèmes.
Le mot paraît très technique. Puis un client reçoit trois fois la même facture, et il devient soudain très concret.
Le système doit savoir échouer proprement
Un workflow fiable n’est pas un workflow qui n’échoue jamais : ce système n’existe pas. C’est un workflow qui prévoit l’échec comme un état possible.
Un document illisible peut être mis de côté. Une information manquante peut déclencher une demande. Une réponse d’IA peu sûre peut appeler une validation. Une panne temporaire peut entraîner une nouvelle tentative, une panne persistante générer une alerte. Et un cas inhabituel peut être confié à une personne sans que l’entreprise ait à retrouver en urgence le développeur d’origine.
Le cadre AI RMF du NIST range la validité, la fiabilité, la sécurité, la résilience et la capacité de surveillance parmi les caractéristiques d’une IA digne de confiance. Il souligne aussi que les risques mesurés en environnement contrôlé peuvent différer de ceux qui apparaissent en conditions réelles. Le document complet est disponible ici.
Même quand un workflow n’utilise aucune intelligence artificielle, le principe reste excellent :
prévoir comment le système se comporte quand il ne peut pas accomplir sa mission.
Une alerte doit conduire à une action
Un système qui envoie cinquante notifications par jour ne surveille pas vraiment son activité. Il délègue son anxiété à l’équipe.
Chaque alerte devrait indiquer :
- ce qui s’est passé ;
- quel élément est concerné ;
- le niveau d’urgence ;
- l’action attendue ;
- et l’endroit où retrouver le détail.
À l’inverse, toutes les anomalies ne justifient pas une alerte immédiate. Une erreur rattrapée automatiquement peut simplement être journalisée, alors qu’un échec persistant ou une donnée sensible exige plus d’attention.
La surveillance utile repose donc sur une distinction assez simple :
ce qui mérite d’être enregistré, ce qui mérite d’être regroupé et ce qui mérite d’interrompre quelqu’un.
Cette dernière catégorie doit rester rare. Sinon, elle finit par être ignorée.
Une validation humaine doit être une vraie validation
« Humain dans la boucle » est une expression très rassurante, qu’on peut caser à peu près partout. Encore faut-il que la personne ait les informations, le temps et l’autorité pour décider.
Un écran qui affiche :
L’IA recommande APPROUVER.
avec un énorme bouton vert « Valider » et un discret « Refuser » gris clair n’est pas forcément un contrôle humain. C’est parfois juste une manière élégante de faire passer la responsabilité de la machine à une personne.
Pour les systèmes d’IA à haut risque, le règlement européen demande que les personnes chargées de la supervision puissent comprendre les capacités et les limites du système, repérer les anomalies, ne pas se fier aveuglément à ses sorties, et interrompre ou ignorer son résultat. L’article 14 détaille ces conditions de supervision.
Toutes les automatisations ne relèvent évidemment pas de ce régime. Mais le principe vaut partout :
si vous placez un humain dans la boucle, donnez-lui réellement les moyens de casser la boucle.
La reprise manuelle ne doit pas être une aventure
Quand un processus automatique s’arrête, l’entreprise doit pouvoir continuer. Cela peut vouloir dire :
- reprendre un dossier à partir de la dernière étape réussie ;
- corriger une donnée puis relancer ;
- basculer temporairement vers un traitement manuel ;
- isoler un cas sans bloquer tous les autres ;
- annuler une action quand c’est possible.
On néglige souvent cette capacité, parce que le scénario nominal absorbe déjà toute l’attention du projet. Elle devient pourtant décisive le jour où le système tombe en panne en plein pic d’activité.
La reprise manuelle n’est pas un aveu d’échec. C’est un mécanisme de continuité.
La maintenance fait partie du produit
Une API évolue. Un logiciel change sa politique d’authentification. Un champ est renommé. Le modèle d’IA est remplacé. Une règle métier devient obsolète. Une nouvelle personne rejoint l’équipe.
Une automatisation n’est donc jamais tout à fait « terminée ». Elle entre simplement dans une phase moins photogénique, qu’on appelle l’exploitation.
La bonne nouvelle, c’est que cette phase n’a pas besoin d’être lourde. Pour un workflow simple, quelques logs propres, des alertes pertinentes, une documentation minimale, des accès maîtrisés et une procédure de reprise peuvent suffire. Pour un système plus critique, les exigences montent : la fiabilité doit être proportionnée au risque.
Personne n’a besoin d’un centre de contrôle spatial pour synchroniser trois lignes dans un CRM. Mais il serait rassurant de savoir quand elles cessent de se synchroniser.
Le meilleur test intervient lorsque quelqu’un casse quelque chose
Plutôt que de démontrer seulement que l’automatisation fonctionne, retirons-lui volontairement une chaise. Supprimons une donnée. Envoyons un doublon. Faisons échouer l’API. Utilisons un document étrange. Refusons la validation. Coupons le workflow au milieu. Puis regardons.
- L’erreur est-elle visible ?
- Le système évite-t-il de produire un doublon ?
- Une personne sait-elle quoi faire ?
- Peut-on reprendre sans perdre le dossier ?
- L’incident laisse-t-il une trace compréhensible ?
Si la réponse est oui, l’automatisation commence à devenir intéressante. S’il faut appeler quelqu’un parce qu’il « connaît un petit truc dans le scénario 17 », il reste encore un peu de travail.
Une automatisation fiable sait raconter ce qui lui est arrivé
Le critère final est presque narratif. Une bonne automatisation doit pouvoir expliquer :
J’ai reçu ceci.
J’ai appliqué cette règle.
Cette étape a réussi.
Celle-ci a échoué.
J’ai arrêté le traitement.
Voici ce qu’une personne doit vérifier.
Ce récit rend le système compréhensible, maintenable et moins dépendant de son créateur.
Une démonstration prouve qu’un scénario peut fonctionner. La fiabilité commence quand le système reste exploitable lorsque ce scénario ne se déroule pas comme prévu.
C’est moins spectaculaire. C’est aussi ce qui distingue un joli prototype d’un outil sur lequel une entreprise peut vraiment compter.