Documenter un processus avant de l’automatiser ou de le déléguer

Mon article original associait l’automatisation à une entreprise qui fonctionnerait presque seule. Il recommandait aussi des plateformes, des rémunérations et une organisation sans tenir compte du droit, du pays ou du contexte. Je retire ces conseils.

L’idée que je conserve est plus simple : avant de confier un travail à un script, à un agent logiciel ou à une autre personne, je dois pouvoir expliquer comment ce travail produit un résultat correct.

Automatiser une procédure floue ne supprime pas ses défauts. Cela permet de les répéter plus vite.

Observer le travail réel

Je commence par exécuter la tâche moi-même et noter ce qui se passe réellement. La procédure imaginée depuis un bureau manque souvent les données incomplètes, les demandes inhabituelles et les décisions prises sans y penser.

Je documente six éléments :

1. le déclencheur de la tâche ;
2. les entrées nécessaires ;
3. les étapes et les décisions ;
4. le résultat attendu ;
5. les erreurs possibles ;
6. la personne responsable du résultat.

Une phrase comme « traiter le remboursement » ne suffit pas. Il faut préciser comment identifier la transaction, vérifier son état, éviter un double remboursement, enregistrer la décision et informer le client.

Simplifier avant d’ajouter un outil

Certaines tâches répétitives existent uniquement parce que deux systèmes demandent la même information ou parce qu’une règle ancienne n’a jamais été remise en question.

Je cherche donc d’abord ce qui peut être supprimé, regroupé ou pris en charge par le produit lui-même. Le meilleur script pour recopier une donnée reste moins fiable qu’une seule source de vérité.

Je sépare ensuite les règles stables des décisions qui dépendent du contexte. Une règle stable peut être automatisée. Une exception rare et coûteuse mérite souvent une validation humaine.

Écrire une procédure exécutable par une autre personne

Une bonne procédure contient des verbes précis, des exemples et un critère de fin. Elle indique aussi ce qu’il ne faut pas faire.

Je la teste avec une personne qui ne possède pas mon contexte. Si elle doit me demander où trouver une donnée, comment choisir entre deux options ou quoi faire après une erreur, la documentation n’est pas terminée.

Cette étape ne sert pas uniquement à déléguer. Elle transforme une connaissance implicite en contrat opérationnel que je peux ensuite traduire en code et en tests.

Choisir ce qui mérite une automatisation

Je donne la priorité aux tâches fréquentes, bien définies et faciles à vérifier. J’évite de commencer par une opération rare qui possède de nombreuses exceptions ou peut produire un dommage difficile à réparer.

L’automatisation doit avoir une valeur mesurable : réduire les erreurs, raccourcir un délai, appliquer une règle de manière cohérente ou retirer un travail répétitif. Gagner quelques clics ne justifie pas toujours un nouveau système à maintenir.

Le chapitre de Google SRE sur l’automatisation insiste sur ce point : l’automatisation apporte de la cohérence, mais elle peut aussi centraliser une erreur. Son périmètre doit donc être défini et contrôlé.

Ajouter les contrôles avant le déclenchement automatique

Pour une tâche qui modifie des données ou contacte des personnes, je vérifie au minimum :

• l’idempotence, afin qu’un nouvel essai ne crée pas un doublon ;
• un mode de simulation quand il est possible ;
• des permissions limitées au besoin réel ;
• une limite de volume ou de fréquence ;
• des journaux qui relient l’entrée, la décision et le résultat ;
• une alerte compréhensible ;
• une méthode pour arrêter, reprendre ou annuler l’opération.

Je teste aussi les entrées manquantes, les délais réseau et les réponses inattendues. Le chemin heureux montre que le script peut fonctionner. Les échecs montrent s’il peut être exploité.

Appliquer la même règle aux agents logiciels

Un agent capable de lire plusieurs outils et d’effectuer des actions ne doit pas recevoir un objectif vague avec des droits étendus.

Je lui donne un périmètre limité, des sources identifiées, un résultat vérifiable et des points d’approbation avant les actions externes importantes. Je conserve une trace des outils appelés et des données modifiées.

Si une personne ne peut pas expliquer comment contrôler le résultat, l’agent ne doit pas encore agir seul.

Déléguer la responsabilité sans perdre la visibilité

Déléguer ne signifie pas abandonner le suivi. Je définis qui décide, qui exécute, qui vérifie et qui intervient en cas d’échec. La personne doit disposer du contexte et de l’autorité nécessaires, pas seulement d’une liste de clics.

Je garde quelques mesures simples : volume traité, erreurs, reprises manuelles et délai. Elles montrent si le processus reste utile lorsque le produit, l’équipe ou les contraintes changent.

La séquence que je retiens est donc la suivante : observer, supprimer l’inutile, documenter, tester, instrumenter, puis automatiser ou déléguer. Cette préparation prend du temps, mais elle évite de transformer une confusion locale en problème récurrent.