Quel processus métier automatiser en premier ?

Vous voyez peut-être une commande copiée d’un courriel vers un tableur, puis ressaisie dans la facturation. La tâche est agaçante, mais ce n’est pas forcément le meilleur premier choix. Commencez par un travail fréquent, dont le résultat se mesure, dont les règles changent peu et dont les données sont fiables. Une personne doit aussi pouvoir reprendre la main si l’outil échoue. Si l’une de ces conditions manque, simplifiez d’abord la procédure ou fiabilisez les données.

Un processus métier est la suite d’étapes qui part d’un événement — une commande reçue, un dossier complet, une date atteinte — et aboutit à un résultat utile. L’automatiser consiste à confier certaines de ces étapes à un logiciel. Cela ne suppose ni intelligence artificielle, ni nouvelle application.

Dans l’ordre : dessinez le travail réel, passez cinq portes qui ne se compensent pas, puis comparez sept réponses. Vous distinguerez ensuite les heures réaffectées de leur valeur de capacité, puis d’une dépense réellement évitée. Vous préparerez enfin un pilote, c’est-à-dire un essai limité qui peut être arrêté sans bloquer l’activité.

Pour vérifier ces conditions, commencez par suivre quelques dossiers de bout en bout.

Ne partez pas du logiciel que vous aimeriez acheter. Suivez plusieurs dossiers jusqu’au bout et notez ce que les personnes font vraiment. Une procédure écrite omet souvent le coup de téléphone, le fichier temporaire ou la vérification qui sauve un cas incomplet.

Le dossier France Num consacré à l’automatisation propose de quantifier la fréquence, la durée, la complexité et l’impact d’une erreur. La carte ci-dessous ajoute les exceptions, les responsabilités et la reprise. Ces éléments montrent si le premier essai restera contrôlable.

CARTE D’UN PROCESSUS — UNE PAGE

Déclencheur : quel événement lance le travail ?
Résultat attendu : qu’est-ce qui prouve qu’il est terminé ?
Volume : combien de cas sur une période représentative ?
Temps actif : combien de minutes réellement travaillées par cas ?
Étapes : qui fait quoi, dans quel outil et dans quel ordre ?
Données : quelle source fait foi pour chaque information ?
Exceptions : quels cas quittent le chemin normal ?
Erreur : comment est-elle détectée et quelle est sa conséquence ?
Reprise : comment poursuivre à la main et éviter un doublon ?
Responsable : qui modifie la règle et qui reçoit l’alerte ?
Mesure après : quel indicateur sera comparé avant et après ?

Suivez des cas, pas seulement une moyenne

Exemple fictif : huit demandes complètes prennent trois minutes chacune et deux demandes ambiguës prennent trente minutes chacune. Le travail total représente 84 minutes. Même si les huit cas simples sont entièrement automatisés, seules 24 minutes deviennent techniquement retirables, soit 28,6 % du temps. « 80 % des dossiers » ne veut donc pas dire « 80 % du temps ». Mesurez séparément le chemin normal, les exceptions et le contrôle restant.

Un tableau de notation additionne souvent gain, fréquence et complexité. Il aide à comparer, mais un gain financier élevé peut y compenser une erreur impossible à reprendre. Commencez plutôt par cinq questions auxquelles la réponse doit être « oui ». Le calcul économique vient seulement après.

Passer les cinq portes ne prouve pas que le projet est rentable. Cela indique seulement qu’un chiffrage et un essai restent raisonnables. Le candidat peut encore perdre face à une fonction déjà payée ou à une simple amélioration de procédure.

Si les cinq conditions sont réunies, le choix reste ouvert : la réponse la plus simple n’est pas toujours un développement.

Comparez toutes les options sur le même résultat, le même volume, la même durée et les mêmes cas d’erreur. Les noms de technologie ne constituent pas un besoin : ils désignent seulement des moyens différents de traiter un processus déjà compris.

Un connecteur n’efface ni les limites ni la surveillance

Les documentations d’éditeur montrent que les flux ont des limites de volume, de durée d’exécution et de conservation des historiques. Certains dépendent aussi du compte d’un utilisateur désigné comme propriétaire. Par exemple, Microsoft documente ces limites pour Power Automate. Elles évoluent selon le produit et la licence : vérifiez la documentation applicable au moment du choix, puis ajoutez les alertes et la maintenance au coût.

Un robot d’interface dépend de l’écran qu’il pilote

Un robot d’interface peut cliquer, lire ou renseigner des éléments d’un écran lorsqu’aucune API utilisable n’est disponible. Dans la documentation Microsoft sur l’automatisation d’interface, ces éléments sont repérés par des repères techniques appelés sélecteurs. Testez leur résistance aux mises à jour, aux fenêtres inattendues, aux sessions expirées et aux changements de droits. Prévoyez aussi le traitement manuel quand le robot ne retrouve plus l’élément attendu.

L’IA traite une incertitude ; elle ne la fait pas disparaître

Pour classer un message ou extraire des champs d’un document, constituez un jeu de cas représentatif, écrivez la réponse correcte et mesurez les erreurs avant le pilote. Le cadre volontaire américain sur les risques de l’intelligence artificielle insiste sur les tests et la surveillance dans la durée. Si le résultat sert à fixer un prix, à écarter une personne ou à déclencher une action difficile à annuler, ajoutez une validation humaine proportionnée.

Quand une option paraît adaptée, il reste à vérifier si les heures réellement réaffectées couvrent tous ses coûts.

Le temps retiré d’une tâche n’est pas automatiquement de l’argent gagné. Une partie des cas peut rester manuelle. Les équipes peuvent contourner l’outil. Les minutes libérées peuvent être trop fragmentées pour éviter une dépense ou accomplir un autre travail. Séparez donc quatre quantités.

1. Heures actuelles : volume × minutes par cas sur la période.
2. Heures techniquement retirables : heures actuelles × part du temps que la solution peut enlever.
3. Heures réellement retirées : heures retirables × adoption moyenne sur toute la période.
4. Heures réaffectées : heures réellement retirées × part confiée à un travail utile identifié.

Heures retirables = heures actuelles × part techniquement retirable
Heures retirées = heures retirables × adoption moyenne
Heures réaffectées = heures retirées × part affectée à un travail utile

Valeur de capacité = heures réaffectées × coût horaire chargé

Coût renseigné = conception, intégration et tests
                  + temps interne
                  + autres coûts ponctuels déjà chiffrés
                  + coût mensuel × durée

Retour sur investissement (ROI) du scénario de capacité
  = (valeur de capacité − coût renseigné) ÷ coût renseigné

La valeur de capacité n’est pas une économie de trésorerie. Elle traduit des heures réaffectées au coût horaire chargé retenu. Une dépense évitée exige la disparition réelle d’un paiement — heures supplémentaires, prestation, recrutement ou autre charge — et ne doit pas être ajoutée une seconde fois pour les mêmes heures.

N’ajoutez la valeur des erreurs évitées, des ventes supplémentaires ou d’un délai réduit que si vous avez mesuré la situation de départ et pouvez expliquer ce qui a produit l’amélioration. Sinon, conservez-les comme bénéfices possibles non chiffrés.

Le calculateur applique ces étapes. Il bloque la décision dès qu’une des cinq portes reste fermée.

Le travail actuel représente 432 heures sur vingt-quatre mois : 120 × 9 ÷ 60 × 24. La solution pourrait en retirer 302,4 heures. Après l’adoption moyenne, 241,92 heures sont réellement retirées de la tâche. Au total, 145,152 heures sont réaffectées, soit une valeur de capacité théorique de 5 515,78 €.

Supposons 4 800 € de conception et de tests, 32 heures de travail interne et 140 € par mois d’abonnement, de suivi et de maintenance. Aucun autre coût ponctuel n’est renseigné dans cet exemple fictif ; cela ne signifie pas qu’un projet réel n’en aurait pas. Le coût renseigné atteint 9 376 € sur vingt-quatre mois : 4 800 + 32 × 38 + 140 × 24.

Le ROI du scénario de capacité est d’environ − 41,2 %. Ce ratio ne représente pas une économie de trésorerie. Avec ces hypothèses, il faut tester une fonction déjà payée, réduire le coût, élargir prudemment le processus ou ne pas investir.

Si le volume change, vérifiez aussi l’abonnement, l’infrastructure et la surveillance. Avec 600 dossiers par mois, l’écart devient positif à coût mensuel inchangé, mais redevient négatif à partir d’environ 899 € par mois dans ce modèle fictif.

Si votre propre scénario reste positif, ne généralisez pas encore : vérifiez-le sur un volume limité en gardant le traitement manuel disponible.

Un pilote est un essai limité, pas un déploiement sur tous les dossiers pendant une semaine. Limitez le volume, gardez le traitement manuel disponible et écrivez les résultats attendus avant de lancer le premier cas.

Écrivez aussi la condition d’arrêt

Arrêtez ou corrigez le pilote si une erreur à forte conséquence échappe au contrôle, si les alertes ne sont pas traitées, si les utilisateurs créent un second processus parallèle ou si le temps résiduel dépasse l’hypothèse économique. Une condition d’arrêt protège mieux qu’une date de déploiement maintenue coûte que coûte.

Ces tests n’ont de valeur que si une personne traite chaque alerte et peut arrêter l’essai.

Qui décide si la règle change ou si le propriétaire du flux part ? Qui traite une alerte ? Écrivez les rôles avec des noms, pas seulement « métier », « informatique » et « prestataire ».

Faites participer les personnes qui réalisent le travail. La boîte à outils de l’Agence nationale pour l’amélioration des conditions de travail (Anact) demande de partir du travail réel et d’associer activement les utilisateurs finaux aux étapes clés du projet. Une démonstration réussie par le prestataire ne montre pas encore que l’équipe saura traiter les exceptions un lundi chargé.

Le niveau de contrôle dépend des données et de la conséquence d’une erreur. La copie d’un document public n’appelle pas les mêmes mesures qu’un changement de coordonnées bancaires, une donnée de santé ou une décision qui affecte une personne. Commencez par les questions suivantes.

• Données : quelles informations entrent, sortent, restent stockées et pendant combien de temps ?
• Accès : chaque personne et chaque compte technique disposent-ils seulement des droits nécessaires ?
• Trace : peut-on relier une action à un dossier, un moment et une version de la règle sans enregistrer des secrets ?
• Continuité : que fait l’équipe lorsque le service ou la connexion ne répond plus ?
• Sauvegarde : les données et la configuration utiles sont-elles restaurables et cette restauration a-t-elle été essayée ?
• Sortie : pouvez-vous récupérer données, configuration, documentation, comptes et, s’il existe, code source dans des formats utilisables ?
• Sous-traitants : quels prestataires et sous-traitants ultérieurs accèdent aux données, depuis quels pays, avec quelles garanties et quelle procédure en fin de contrat ?

Le guide de sécurité des données personnelles de la CNIL couvre notamment les droits d’accès, la journalisation, les sauvegardes testées, la continuité et les API. Si un prestataire traite des données personnelles pour votre compte, la fiche CNIL sur la sous-traitance demande un contrat qui répartit les responsabilités, encadre les incidents et prévoit la restitution ou la destruction des données.

Une décision automatisée peut demander une analyse distincte

L’article 22 ne vise ni toute automatisation ni toute utilisation d’IA. Son champ suppose une décision individuelle fondée sur des données personnelles, prise exclusivement par un traitement automatisé dans les faits, et produisant un effet juridique ou un effet similaire significatif. La CNIL précise ce champ. Un simple classement sans conséquence comparable ne suffit pas ; il peut en revanche devenir significatif si, en pratique, il ferme l’accès à un service, à un emploi, à un contrat ou applique un tarif plus élevé sans réexamen réel.

Le consentement explicite, la nécessité de conclure ou d’exécuter un contrat, ou une disposition légale peuvent constituer des exceptions prévues par le règlement général sur la protection des données (RGPD). Elles ne dispensent pas des garanties applicables. La personne doit notamment pouvoir être informée, exprimer son point de vue, contester la décision et obtenir une intervention humaine. Cette intervention doit permettre un réexamen réel, pas seulement valider mécaniquement la sortie de l’outil.

Même lorsque l’article 22 ne s’applique pas, une analyse d’impact relative à la protection des données (AIPD) est requise si le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés. Vérifiez ce besoin avant le pilote avec le responsable du traitement et le DPO. L’usage d’une IA, à lui seul, ne permet ni de conclure qu’une AIPD est toujours requise, ni de l’écarter.

À ce stade, ne demandez pas encore « combien coûte une automatisation ? ». Préparez une fiche que la direction, les utilisateurs et un prestataire peuvent contester avec les mêmes informations.

FICHE DE DÉCISION

Processus choisi et résultat attendu :
Volume, temps actif et période de mesure :
Exceptions observées :
Cinq portes : ouvertes / action nécessaire :
Réponse la plus simple retenue et options écartées :
Heures retirables, adoption moyenne et heures réaffectées :
Valeur de capacité et dépense réellement évitée, sans double compte :
Coûts ponctuels, mensuels et coût de sortie à confirmer :
Données, droits d’accès et validation humaine :
Cas de test, alerte, reprise manuelle et condition d’arrêt :
Responsable métier et responsable des alertes :
Date et mesure de la décision après pilote :

La décision peut être « activer la fonction existante », « lancer un pilote limité », « simplifier puis mesurer à nouveau » ou « garder cette décision humaine ». Ces quatre sorties sont valables. Le développement sur mesure n’est pertinent que si les règles, les rôles, les écrans ou les intégrations propres à l’entreprise justifient ce coût supplémentaire.

Si vous ne savez pas encore si vos blocages justifient un nouvel outil, commencez par le diagnostic en trois situations. Il permet d’écarter d’abord un risque d’accès, une étape inutile ou une fonction déjà disponible, avant de choisir un processus à automatiser.

Si votre fiche montre qu’un même besoin relie plusieurs équipes ou logiciels, consultez la page consacrée aux outils internes sur mesure. Elle explique le type de projet étudié. Pour reprendre cette méthode sur un autre sujet, revenez au répertoire des guides Hagnéré Code.

Avant d’outiller le processus retenu, deux vérifications évitent de construire au mauvais endroit. Le calcul du retour sur investissement chiffre ce que l’automatisation libère vraiment, et distingue une facture évitée d’un temps rendu disponible. Si l’équipe a déjà bricolé une solution, la comparaison porte alors sur Airtable ou Notion face à une application métier — ou sur Power Apps face à une application sur mesure dans un environnement Microsoft.

Une fois le processus choisi, trois dossiers cadrent l’exécution : le cahier des charges pour figer les règles et les exceptions, la gestion des droits d’accès pour décider qui valide et qui corrige, et le plan de recette pour prouver que l’automatisation tient sur les cas difficiles, pas seulement sur le cas nominal.