Pourquoi un process automatisé doit d'abord être compris avant d'être codé

La tentation, face à un processus lent, est de passer directement à la solution technique. Écrire le script, connecter les systèmes, livrer rapidement. Cette approche fonctionne rarement du premier coup et coûte souvent plus cher que prévu, parce qu'une étape essentielle a été sautée : comprendre le processus réel avant de le transformer en code.

Ce que « comprendre le processus » veut dire concrètement

Ce n'est pas la même chose que lire une procédure écrite. La procédure documentée décrit souvent le cas idéal, celui qui se déroule sans accroc. Le travail réel comprend des exceptions, des contournements appris avec l'expérience et des décisions qui ne figurent dans aucun document.

Comprendre un processus demande donc d'observer comment il se déroule réellement, ou d'interroger en détail les personnes qui l'exécutent au quotidien. Quelles informations sont vérifiées avant de commencer ? Que fait-on lorsqu'une donnée manque ? Que se passe-t-il lorsque deux règles semblent se contredire ? Qui prend la décision lorsqu'un cas sort du scénario habituel ?

Même un cas qui ne se présente que quelques fois par an peut être important s'il représente un montant élevé, un risque particulier ou une situation que l'équipe ne peut pas simplement laisser de côté.

Pourquoi sauter cette étape coûte cher

Une automatisation construite sur une compréhension incomplète du processus peut fonctionner correctement sur le cas standard, puis échouer dès qu'elle rencontre une situation que personne n'avait documentée. À ce moment, il faut soit corriger la solution, soit reprendre manuellement le traitement concerné, parfois les deux.

Une correction faite après le développement peut aussi remettre en cause des choix déjà réalisés. Si l'exception modifie une hypothèse de départ, il ne suffit pas toujours d'ajouter une condition au code : une partie du fonctionnement doit parfois être repensée et retestée.

La confiance de l'équipe dans la solution peut également diminuer. Une automatisation qui échoue régulièrement sur des cas que les utilisateurs connaissent mais que le système ne reconnaît pas pousse naturellement les équipes à vérifier les résultats manuellement. Le gain de temps attendu disparaît alors progressivement.

Comment mener cette étape correctement

Commencer par rassembler des cas réels, pas uniquement des exemples théoriques. Des dossiers, des e-mails, des fichiers ou des traitements effectivement réalisés dans le passé permettent de voir les variations qui n'apparaissent pas dans une procédure standard.

Classer ensuite les cas rencontrés : le cas fréquent et simple, les variantes courantes et les exceptions rares mais réelles. Cette classification permet de décider ce qui peut être automatisé dès la première version, ce qui nécessite encore une validation humaine et ce qui doit rester manuel pour le moment.

Faire enfin valider cette compréhension par les personnes qui exécutent le processus aujourd'hui, avant d'écrire la moindre ligne de code. Elles connaissent souvent des règles implicites, des raccourcis et des situations particulières qu'un observateur extérieur ne repérerait pas.

Cette étape permet aussi de définir un périmètre réaliste pour la première version. L'objectif n'est pas forcément d'automatiser cent pour cent du processus dès le départ, mais de traiter correctement une partie suffisamment représentative pour démontrer le gain et identifier ce qui reste à résoudre.

En résumé

Le temps passé à comprendre un processus avant de l'automatiser n'est pas un délai supplémentaire avant le vrai travail. C'est une partie essentielle du travail, celle qui permet de définir les règles, d'identifier les exceptions et de choisir un périmètre réaliste. Une automatisation solide commence par une observation honnête de la façon dont le travail se fait réellement, exceptions comprises.