[{"data":1,"prerenderedAt":78},["ShallowReactive",2],{"editorial:\u002Fressources\u002Fcomment-savoir-si-un-processus-merite-automatisation":3},{"categories":4,"preview":23,"path":24,"kind":25,"title":26,"article":27,"noindex":23},[5,8,11,14,17,20],{"slug":6,"label":7},"automatisation","Automatisation",{"slug":9,"label":10},"equipes-transformation","Équipes & transformation",{"slug":12,"label":13},"workflows-processus","Workflows & processus",{"slug":15,"label":16},"agents-ia","Agents IA",{"slug":18,"label":19},"fiabilite-exploitation","Fiabilité & exploitation",{"slug":21,"label":22},"gouvernance-autonomie","Gouvernance & autonomie",false,"\u002Fressources\u002Fcomment-savoir-si-un-processus-merite-automatisation","article","Comment savoir si un processus mérite vraiment d’être automatisé ?",{"id":28,"title":26,"slug":28,"category":6,"excerpt":29,"coverImage":30,"coverAlt":31,"status":32,"featured":23,"publishedAt":33,"updatedAt":33,"author":34,"seoTitle":35,"seoDescription":36,"relatedCaseStudy":37,"relatedTraining":38,"readingTime":39,"url":24,"html":40,"toc":41,"training":69,"caseStudy":74,"breadcrumbTitle":77},"comment-savoir-si-un-processus-merite-automatisation","Tous les processus répétitifs ne sont pas de bons candidats à l’automatisation. Certains méritent d’être accélérés. D’autres d’être repensés. Et quelques-uns mériteraient surtout qu’on arrête de les faire.","\u002Fassets\u002Fressources\u002Farticles\u002Fcomment-savoir-si-un-processus-merite-automatisation.jpg","Un espace de travail où plusieurs tâches sont triées avant de décider lesquelles automatiser","published","2026-10-12","RIKŌ","Comment savoir si un processus doit être automatisé ?","Fréquence, stabilité, exceptions, coût d’erreur : une méthode simple pour identifier les processus qui méritent réellement une automatisation.","demandes-entrantes","voir-clair-avant-automatiser",7,"\u003Ch2 id=\"la-premiere-automatisation-devrait-parfois-etre-une-suppression\" tabindex=\"-1\">La première automatisation devrait parfois être une suppression\u003C\u002Fh2>\n\u003Cp>Une tâche prend quinze minutes. Elle revient trois fois par jour. Quelqu’un sort la calculatrice : quarante-cinq minutes par jour, environ deux cent vingt jours par an, le chiffre commence à avoir fière allure dans un tableau. Le dossier semble réglé.\u003C\u002Fp>\n\u003Cp>Automatisons.\u003C\u002Fp>\n\u003Cp>Pas si vite. Il manque une question légèrement importante :\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Pourquoi faisons-nous encore cette tâche ?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Certains processus répétitifs ne sont pas inefficaces, ils sont inutiles. Un reporting peut être parfaitement automatisable sans être lu par personne. Une validation a peut-être été ajoutée six ans plus tôt après un incident qui ne peut techniquement plus se reproduire. Une ressaisie entre deux logiciels existe parfois simplement parce que personne n’a vérifié s’ils savaient déjà communiquer.\u003C\u002Fp>\n\u003Cp>Automatiser une absurdité a un avantage : elle devient beaucoup plus rapide. Elle reste une absurdité.\u003C\u002Fp>\n\u003Cp>Avant de choisir un outil, la première étape consiste donc parfois à supprimer, fusionner ou simplifier le processus. Le meilleur workflow est, à l’occasion, celui qu’on ne construira jamais.\u003C\u002Fp>\n\u003Ch2 id=\"un-bon-candidat-possede-un-debut-une-fin-et-quelques-regles-stables\" tabindex=\"-1\">Un bon candidat possède un début, une fin et quelques règles stables\u003C\u002Fh2>\n\u003Cp>Les processus les plus faciles à automatiser ont en général plusieurs points communs. Ils se répètent. Leur déclencheur est identifiable. Les données nécessaires existent. Les principales règles restent assez stables. Et on sait reconnaître un résultat correct.\u003C\u002Fp>\n\u003Cp>Une demande arrive dans une boîte définie. Une facture suit un format exploitable. Une échéance déclenche une relance. Un dossier change d’état quand un ensemble de conditions est réuni. Tout cela se prête assez bien à l’automatisation.\u003C\u002Fp>\n\u003Cp>À l’inverse, si chaque occurrence impose une réunion de vingt minutes pour décider ce que signifie le mot « normalement », le chantier demande sans doute encore un peu de clarification.\u003C\u002Fp>\n\u003Cp>Le cadre de gestion des risques liés à l’IA du NIST part justement de la compréhension du contexte, des objectifs, des bénéfices attendus, des personnes concernées et des limites d’un système. Sa fonction \u003Cstrong>Map\u003C\u002Fstrong> sert notamment à déterminer si l’usage envisagé répond bien au problème réel. \u003Ca href=\"https:\u002F\u002Fdoi.org\u002F10.6028\u002FNIST.AI.100-1\" target=\"_blank\" rel=\"noopener noreferrer\">Le document ne commence pas par le choix d’un modèle ou d’un outil\u003C\u002Fa>, et ce n’est pas un hasard.\u003C\u002Fp>\n\u003Cp>Beaucoup de projets démarrent pourtant par :\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Nous voulons utiliser l’IA pour…\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>La phrase utile serait plutôt :\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Nous voulons résoudre…\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Quelques mots de différence peuvent épargner plusieurs mois d’enthousiasme mal placé.\u003C\u002Fp>\n\u003Ch2 id=\"la-frequence-compte-mais-la-friction-compte-davantage\" tabindex=\"-1\">La fréquence compte, mais la friction compte davantage\u003C\u002Fh2>\n\u003Cp>Une tâche réalisée cinq cents fois par mois attire naturellement l’attention. Mais une opération qui n’a lieu que dix fois peut coûter plus cher si elle mobilise quatre personnes, interrompt un responsable, réclame des informations dispersées ou provoque régulièrement des erreurs.\u003C\u002Fp>\n\u003Cp>Le coût d’un processus ne se résume pas au chronomètre. Il y a aussi :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>le coût des interruptions ;\u003C\u002Fli>\n\u003Cli>le temps d’attente entre deux personnes ;\u003C\u002Fli>\n\u003Cli>la recherche d’informations ;\u003C\u002Fli>\n\u003Cli>la vérification ;\u003C\u002Fli>\n\u003Cli>les erreurs et leurs corrections ;\u003C\u002Fli>\n\u003Cli>la dépendance à une personne ;\u003C\u002Fli>\n\u003Cli>le temps nécessaire pour former un nouveau collaborateur.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Et puis il y a cette tâche que tout le monde repousse au vendredi après-midi, avec un optimisme collectif assez mystérieux.\u003C\u002Fp>\n\u003Cp>Une bonne analyse s’intéresse donc moins à la durée brute qu’à \u003Cstrong>la friction produite autour du travail\u003C\u002Fstrong>. Un contrôle de deux minutes peut être un excellent candidat s’il interrompt trente fois une journée. Une opération de vingt minutes peut très bien rester telle quelle si elle demande un jugement rare, utile, exercé par la bonne personne.\u003C\u002Fp>\n\u003Ch2 id=\"il-faut-compter-les-exceptions-avant-de-celebrer-le-scenario-nominal\" tabindex=\"-1\">Il faut compter les exceptions avant de célébrer le scénario nominal\u003C\u002Fh2>\n\u003Cp>Imaginons un workflow qui traite mille dossiers par mois. Sur huit cent cinquante, les règles sont simples. Sur cent, il manque une information. Sur quarante, une particularité métier apparaît. Sur dix, quelqu’un doit prendre une décision sensible.\u003C\u002Fp>\n\u003Cp>On tient déjà une architecture possible :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>les huit cent cinquante premiers dossiers avancent automatiquement ;\u003C\u002Fli>\n\u003Cli>les cent suivants déclenchent une demande d’information ;\u003C\u002Fli>\n\u003Cli>les quarante cas particuliers sont préparés par le système ;\u003C\u002Fli>\n\u003Cli>les dix situations sensibles arrivent devant une personne.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>On n’a pas « automatisé le processus ». On a automatisé \u003Cstrong>la partie du processus qui méritait de l’être\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Cette manière de raisonner par tâches rejoint les travaux de l’OIT sur l’exposition des métiers à l’IA générative. L’étude ne traite pas chaque profession comme un bloc indivisible : elle examine des milliers de tâches pour estimer ce que la technologie peut réellement transformer. \u003Ca href=\"https:\u002F\u002Fwww.ilo.org\u002Fpublications\u002Fgenerative-ai-and-jobs-refined-global-index-occupational-exposure\" target=\"_blank\" rel=\"noopener noreferrer\">Cette granularité permet de distinguer l’exposition d’un métier de sa disparition\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>La même discipline sert dans une entreprise. Ne demandez pas :\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Peut-on automatiser la comptabilité ?\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>La question est trop large pour produire une réponse exploitable. Demandez plutôt :\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>Parmi les opérations qui composent ce travail, lesquelles sont déterministes, lesquelles peuvent être préparées et lesquelles exigent un jugement ?\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Là, le projet commence à prendre une forme raisonnable.\u003C\u002Fp>\n\u003Ch2 id=\"le-cout-d-une-erreur-decide-souvent-du-niveau-d-autonomie\" tabindex=\"-1\">Le coût d’une erreur décide souvent du niveau d’autonomie\u003C\u002Fh2>\n\u003Cp>Une IA qui classe mal un email non critique peut être agaçante. Un système qui déclenche un remboursement, modifie un contrat ou envoie une information confidentielle à cause d’une mauvaise interprétation relève d’une tout autre conversation.\u003C\u002Fp>\n\u003Cp>Deux automatisations qui font gagner le même temps peuvent donc justifier des niveaux d’autonomie très différents.\u003C\u002Fp>\n\u003Cp>Le NIST définit le risque en combinant la probabilité d’un événement et l’ampleur de ses conséquences. Il recommande de tenir compte du contexte réel, des impacts possibles et de la tolérance au risque propre à l’organisation. \u003Ca href=\"https:\u002F\u002Fdoi.org\u002F10.6028\u002FNIST.AI.100-1\" target=\"_blank\" rel=\"noopener noreferrer\">Le cadre insiste aussi sur l’écart entre les résultats mesurés en environnement contrôlé et ceux qu’on observe dans l’usage réel\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>On peut le résumer simplement :\u003C\u002Fp>\n\u003Cp>\u003Cstrong>plus l’erreur est chère, réglementée, irréversible ou difficile à détecter, moins on improvise.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Et parfois, la meilleure automatisation n’exécute aucune action sensible. Elle prépare, elle vérifie, elle alerte, puis elle laisse une personne décider. C’est déjà beaucoup.\u003C\u002Fp>\n\u003Ch2 id=\"les-donnees-doivent-etre-accessibles-et-suffisamment-propres\" tabindex=\"-1\">Les données doivent être accessibles et suffisamment propres\u003C\u002Fh2>\n\u003Cp>Un processus peut paraître idéal sur le papier, puis buter sur un détail : l’information nécessaire n’existe pas sous une forme exploitable. Elle se trouve dans des emails. Dans des fichiers nommés \u003Ccode>FINAL_v3_bis\u003C\u002Fcode>. Dans un champ libre que chacun remplit à sa façon. Ou dans la mémoire de quelqu’un qui part en congé jeudi.\u003C\u002Fp>\n\u003Cp>Avant d’automatiser, il faut donc vérifier :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>où se trouvent les données ;\u003C\u002Fli>\n\u003Cli>qui peut y accéder ;\u003C\u002Fli>\n\u003Cli>si elles sont structurées ;\u003C\u002Fli>\n\u003Cli>si elles sont fiables ;\u003C\u002Fli>\n\u003Cli>si leur usage est autorisé ;\u003C\u002Fli>\n\u003Cli>et ce qui se passe quand elles sont absentes.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Une automatisation n’améliore pas magiquement une donnée médiocre. Elle peut seulement la propager beaucoup plus efficacement. Ce n’est pas tout à fait la même promesse.\u003C\u002Fp>\n\u003Ch2 id=\"le-processus-doit-avoir-un-proprietaire\" tabindex=\"-1\">Le processus doit avoir un propriétaire\u003C\u002Fh2>\n\u003Cp>Une automatisation sans responsable finit souvent dans une zone floue. Tout le monde l’utilise, personne ne décide vraiment de ses évolutions. Les règles changent, mais le workflow continue d’appliquer celles de l’an dernier. Une anomalie apparaît, et chacun suppose que quelqu’un d’autre la surveille.\u003C\u002Fp>\n\u003Cp>Avant de construire, il faut donc identifier une personne ou une équipe capable de répondre à quelques questions :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Quel résultat attendons-nous ?\u003C\u002Fli>\n\u003Cli>Qui valide les règles ?\u003C\u002Fli>\n\u003Cli>Qui traite les exceptions ?\u003C\u002Fli>\n\u003Cli>Qui décide qu’une évolution est nécessaire ?\u003C\u002Fli>\n\u003Cli>Qui peut arrêter le système en cas de problème ?\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Le propriétaire n’a pas besoin de développer la solution. Il doit pouvoir comprendre ce qu’elle fait et assumer les décisions métier qui l’entourent.\u003C\u002Fp>\n\u003Ch2 id=\"le-succes-doit-etre-mesurable-autrement-que-par-ca-fonctionne\" tabindex=\"-1\">Le succès doit être mesurable autrement que par « ça fonctionne »\u003C\u002Fh2>\n\u003Cp>« Gagner du temps » est une intention, pas encore une mesure. Avant le projet, il faut décrire ce qu’on veut vraiment changer :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>réduire le délai moyen de traitement ;\u003C\u002Fli>\n\u003Cli>diminuer le nombre de demandes oubliées ;\u003C\u002Fli>\n\u003Cli>supprimer une ressaisie ;\u003C\u002Fli>\n\u003Cli>réduire les erreurs ;\u003C\u002Fli>\n\u003Cli>raccourcir la montée en compétence ;\u003C\u002Fli>\n\u003Cli>rendre le suivi moins dépendant de la mémoire individuelle ;\u003C\u002Fli>\n\u003Cli>permettre à l’équipe d’absorber un pic d’activité.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Après le déploiement, on compare. Et il arrive que le résultat déçoive. C’est mauvais pour la petite musique triomphale de la présentation finale, mais excellent pour l’entreprise : elle sait désormais ce qui marche et ce qui ne mérite pas d’être étendu.\u003C\u002Fp>\n\u003Ch2 id=\"une-grille-simple-permet-deja-de-faire-beaucoup-de-tri\" tabindex=\"-1\">Une grille simple permet déjà de faire beaucoup de tri\u003C\u002Fh2>\n\u003Cp>Quand un processus semble intéressant, quelques questions suffisent pour commencer :\u003C\u002Fp>\n\u003Col>\n\u003Cli>Est-il réellement nécessaire ?\u003C\u002Fli>\n\u003Cli>Est-il suffisamment fréquent, coûteux ou irritant ?\u003C\u002Fli>\n\u003Cli>Son début et son résultat sont-ils identifiables ?\u003C\u002Fli>\n\u003Cli>Les données nécessaires existent-elles ?\u003C\u002Fli>\n\u003Cli>Ses règles sont-elles relativement stables ?\u003C\u002Fli>\n\u003Cli>Combien d’exceptions produit-il ?\u003C\u002Fli>\n\u003Cli>Quel est le coût d’une erreur ?\u003C\u002Fli>\n\u003Cli>Qui conserve la responsabilité du processus ?\u003C\u002Fli>\n\u003Cli>Comment mesurerons-nous le résultat ?\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Si les réponses restent floues, cela ne veut pas dire que l’automatisation est impossible. Cela veut simplement dire que la prochaine étape n’est probablement pas encore de choisir une plateforme, un agent ou un modèle.\u003C\u002Fp>\n\u003Cp>Et c’est très bien. L’entreprise vient déjà d’éviter d’automatiser quelque chose qu’elle ne comprenait pas. C’est un premier gain tout à fait honorable.\u003C\u002Fp>\n\u003Csection class=\"article-sources\" aria-labelledby=\"sources\">\n\u003Ch2 id=\"sources\" tabindex=\"-1\">Sources\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fdoi.org\u002F10.6028\u002FNIST.AI.100-1\" target=\"_blank\" rel=\"noopener noreferrer\">NIST — \u003Cem>Artificial Intelligence Risk Management Framework 1.0\u003C\u002Fem>\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.ilo.org\u002Fpublications\u002Fgenerative-ai-and-jobs-refined-global-index-occupational-exposure\" target=\"_blank\" rel=\"noopener noreferrer\">Organisation internationale du Travail — \u003Cem>Generative AI and Jobs: A Refined Global Index of Occupational Exposure\u003C\u002Fem>\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fai-act-service-desk.ec.europa.eu\u002Fen\u002Fai-act\u002Farticle-14\" target=\"_blank\" rel=\"noopener noreferrer\">Commission européenne — AI Act, article 14 : Human oversight\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fsection>\n",[42,45,48,51,54,57,60,63,66],{"id":43,"title":44},"la-premiere-automatisation-devrait-parfois-etre-une-suppression","La première automatisation devrait parfois être une suppression",{"id":46,"title":47},"un-bon-candidat-possede-un-debut-une-fin-et-quelques-regles-stables","Un bon candidat possède un début, une fin et quelques règles stables",{"id":49,"title":50},"la-frequence-compte-mais-la-friction-compte-davantage","La fréquence compte, mais la friction compte davantage",{"id":52,"title":53},"il-faut-compter-les-exceptions-avant-de-celebrer-le-scenario-nominal","Il faut compter les exceptions avant de célébrer le scénario nominal",{"id":55,"title":56},"le-cout-d-une-erreur-decide-souvent-du-niveau-d-autonomie","Le coût d’une erreur décide souvent du niveau d’autonomie",{"id":58,"title":59},"les-donnees-doivent-etre-accessibles-et-suffisamment-propres","Les données doivent être accessibles et suffisamment propres",{"id":61,"title":62},"le-processus-doit-avoir-un-proprietaire","Le processus doit avoir un propriétaire",{"id":64,"title":65},"le-succes-doit-etre-mesurable-autrement-que-par-ca-fonctionne","Le succès doit être mesurable autrement que par « ça fonctionne »",{"id":67,"title":68},"une-grille-simple-permet-deja-de-faire-beaucoup-de-tri","Une grille simple permet déjà de faire beaucoup de tri",{"title":70,"subtitle":71,"number":72,"url":73},"Voir clair avant d’automatiser","Tout ce qui peut être automatisé ne mérite pas forcément de l’être.",1,"\u002Fformation#formation-1",{"title":75,"url":76},"Demandes entrantes","\u002Fcas-concrets#cas-01","Comment savoir si un processus mérite vraiment d’être automatisé ",1791847724169]