Certains processus semblent plus simples qu'ils ne le sont. Quelqu'un prend un modèle, adapte quelques données, choisit une langue, donne au document un numéro de séquence et l'enregistre. Si cette action revient régulièrement, l'automatisation semble une évidence.

Jusqu'à ce que vous commenciez à poser des questions. Pourquoi ce numéro de séquence est-il construit exactement de cette façon ? Quelles combinaisons sont autorisées, et lesquelles ne le sont pas ? Que se passe-t-il lorsqu'un même contrat concerne plusieurs personnes ? Quels documents existants déterminent quel numéro suit, et qui peut décider qu'une exception est malgré tout autorisée ? Vous découvrez alors que vous n'êtes pas en train d'automatiser un document Word. Vous êtes en train de formaliser un processus qui, pendant des années, a vécu en partie dans des fichiers et en partie dans la tête des gens.

Le logiciel est plutôt bon pour exécuter des règles. La difficulté consiste à déterminer quelles règles existent réellement. Celui qui exécute une routine manuellement remarque rarement combien de décisions implicites il prend en chemin : qu'un numéro déjà utilisé n'est jamais réutilisé, qu'un client donné est toujours traité juste un peu différemment, qu'une certaine combinaison « ne se produit pas » — jusqu'au jour où quelqu'un la saisit tout de même. Tant qu'un être humain exécute le processus, l'expérience comble ces vides. Le logiciel ne le fait pas. Et c'est justement utile : une bonne automatisation oblige à remplacer le « normalement, on fait comme ça » par des règles suffisamment claires pour être appliquées et testées. Il faut alors définir ce qui est obligatoire, ce qui est bloqué, ce qui doit rester unique, quelles données font foi et ce qui se passe lorsqu'une étape échoue.

Ce n'est qu'ensuite que la technologie devient intéressante. Un outil qui fait gagner vingt secondes dans une démo ne me sert pas à grand-chose si je ne sais pas avec certitude si deux utilisateurs peuvent obtenir le même numéro de séquence, ou si des données existantes risquent d'être écrasées lors d'un transfert. C'est pourquoi, pour les outils internes, je regarde d'abord ce qui ne peut absolument pas se produire. Un bouton qui fonctionne a peu de valeur si les exceptions à côté ne sont pas fiables.

Cela détermine aussi la façon dont j'utilise l'IA dans un tel projet. Un modèle peut aider à écrire du code, proposer des cas de test, remettre en question une conception ou révéler des scénarios auxquels personne n'avait pensé. Utile. Mais « l'IA a fait le code » ne dit rien de la qualité du résultat. Là où une règle métier doit être fixée, un modèle ne peut pas se mettre à deviner silencieusement quel type, quel numéro ou quelle langue s'applique. Ce qui compte, c'est de savoir si la même entrée donne à chaque fois le résultat voulu, si les erreurs sont bloquées avant d'endommager les données, et s'il existe des tests pour le comportement qui doit être préservé.

Tout jugement humain ne doit pas pour autant disparaître. Certaines décisions, vous les gardez délibérément entre les mains d'un utilisateur. Si un outil reprend dix actions et laisse une décision importante à un humain, c'est souvent préférable à automatiser onze actions en espérant que la onzième se passe toujours bien. Pour moi, automatiser ne consiste pas à supprimer un maximum d'étapes, mais à retirer la routine de façon fiable sans automatiser aussi le contrôle.

La même chose vaut pour ce qui existe déjà. Un nouvel outil hérite rarement d'un terrain vierge : il y a des documents, des numéros, des dossiers et des habitudes antérieurs à l'outil, et cela fait partie du problème. Une automatisation qui fonctionne ne doit pas seulement savoir ce qui doit se passer demain. Elle doit aussi respecter ce qui s'est déjà passé hier.

C'est pourquoi je préfère commencer par une question désagréable : que cet outil ne doit-il absolument jamais faire de travers ? Tant qu'il n'existe pas de réponse claire à cette question, nous ne sommes pas encore prêts à automatiser.