Ton automatisation fonctionne. Mais qui en est réellement responsable ?

Il y a un moment assez agréable dans un projet d’automatisation.

On construit quelque chose.

On le teste.

On corrige deux ou trois détails.

Puis ça fonctionne.

Les mails arrivent au bon endroit. Les documents sont créés. Les informations passent d’un outil à l’autre. Une tâche qui occupait quelqu’un tous les jours se fait désormais presque toute seule.

À ce moment-là, on considère souvent le projet comme terminé.

Je pense qu’il manque une question.

Qui possède maintenant ce système ?

Pas qui l’a construit.

Qui en est responsable six mois plus tard.

Le problème apparaît rarement le premier jour

Quand quelqu’un construit une automatisation, il connaît tout.

Pourquoi cette règle existe.

Pourquoi ce fichier est utilisé.

Pourquoi tel client passe par une branche différente.

Pourquoi cette étape ne doit surtout pas être déplacée.

Une grande partie du fonctionnement existe dans sa tête.

Puis le temps passe.

Le système devient banal.

Et c’est plutôt bon signe.

Jusqu’au jour où quelque chose change.

Un compte est remplacé.

Une colonne est renommée.

Une offre commerciale évolue.

Un fournisseur change son format.

L’automatisation continue peut-être de tourner.

Mais plus personne ne sait exactement ce qu’elle devrait faire maintenant.

Le constructeur n’est pas forcément le propriétaire

C’est une distinction que je trouve importante.

Celui qui monte une voiture n’est pas celui qui prend toutes les décisions pendant la course.

Autour de la machine, il existe des responsabilités différentes.

Quelqu’un connaît la mécanique.

Quelqu’un connaît la stratégie.

Quelqu’un conduit.

Dans une automatisation métier, on peut retrouver la même logique.

La personne technique peut maintenir le système.

Mais quelqu’un côté métier doit pouvoir dire :

« Oui, cette règle est toujours correcte. »

Ou :

« Non, notre façon de travailler a changé depuis juillet. »

Sans cette responsabilité, on finit par entretenir parfaitement une automatisation qui reproduit une ancienne organisation.

Donner un propriétaire ne veut pas dire créer un nouveau poste

Il n’est pas nécessaire d’avoir un « responsable IA » pour chaque petit scénario.

Le propriétaire peut simplement être la personne qui connaît suffisamment le processus pour répondre à quelques questions :

Est-ce que cette automatisation sert toujours ?

Les règles qu’elle applique sont-elles encore vraies ?

Que fait-on lorsqu’elle rencontre un cas inhabituel ?

Qui doit être prévenu si elle ne fonctionne plus ?

Qui valide une modification importante ?

Cela suffit déjà à éviter beaucoup de flottement.

Une automatisation abandonnée peut continuer à très bien fonctionner

C’est peut-être le piège le plus intéressant.

On imagine facilement une automatisation abandonnée comme quelque chose qui tombe en panne.

Mais elle peut continuer à fonctionner parfaitement.

Elle traite cent pour cent des dossiers.

Aucune erreur technique.

Aucune alerte.

Simplement, l’entreprise ne travaille plus exactement de la même manière.

La machine exécute très bien une règle devenue mauvaise.

C’est beaucoup plus difficile à détecter.

Le vrai passage en production

Pour moi, une automatisation n’est donc pas complètement terminée lorsqu’elle fonctionne.

Elle l’est quand l’entreprise sait aussi :

qui la surveille ;

qui comprend encore son objectif ;

qui peut décider qu’elle doit changer ;

et qui peut décider qu’elle doit disparaître.

C’est moins spectaculaire qu’une démonstration.

Mais c’est ce qui transforme un bricolage intelligent en véritable outil de travail.

Au Mans, une voiture ne prend pas le départ simplement parce que son moteur tourne.

Il faut aussi une équipe qui sache quoi en faire pendant toute la course.

Pour une automatisation, c’est exactement pareil.