Comment naissent les processus métiers : du travail réel aux outils logiciels

La création des processus métiers est souvent présentée comme une démarche de standardisation des bonnes pratiques. Pourtant, dans toutes les organisations, les processus métiers ne cessent d’être créés, adaptés ou remplacés.

Cette dynamique permanente est parfois interprétée comme un manque de discipline, une résistance au changement ou un défaut d’outillage. Elle constitue pourtant une propriété fondamentale du travail humain : lorsqu’un environnement évolue, les acteurs doivent inventer de nouvelles façons de coordonner leurs actions, de résoudre des problèmes et de créer de la valeur.

Dans cet article, nous montrons que, loin d’être un obstacle à la performance, cette capacité à faire évoluer continuellement les processus peut constituer un solide avantage concurrentiel.

La scène est banale : un comité projet réunit un directeur métier, quelques responsables opérationnels et un chef de projet chargé de remplacer un processus jugé « obsolète ». Au détour d’une démonstration, un tableur apparaît à l’écran.

Le silence dure quelques secondes, puis vient presque toujours la même remarque :

« Vous utilisez encore Excel pour gérer ce processus ? »

Dans l’esprit de beaucoup de décideurs, la question est légitime. Si ce processus est important, pourquoi n’existe-t-il pas déjà un logiciel spécialisé ? Et si un logiciel existe, pourquoi continuer à utiliser un tableur ?

Cette réaction traduit une conviction très répandue, rarement formulée explicitement mais profondément ancrée dans le management moderne : pour chaque tâche importante, il existerait une « meilleure façon de faire ». Une fois cette « bonne pratique » identifiée, un éditeur finirait nécessairement par la transformer en logiciel. Finalement, le rôle de l’entreprise se limiterait alors à choisir le bon outil.

Cette représentation paraît tellement naturelle qu’elle semble relever du bon sens, et pourtant, elle est globalement inexacte. Plus précisément, elle n’est vraie que dans une catégorie très particulière d’activités.

Déconstruire cette idée reçue est nécessaire pour comprendre comment les processus métiers naissent, évoluent et disparaissent continuellement dans toutes les organisations.

La standardisation des processus métiers : l’héritage de la « one best way »

Cette manière de penser n’est pas apparue avec l’informatique : elle plonge ses racines dans la révolution industrielle.

Au XIXᵉ siècle, la fabrication en série impose l’interchangeabilité des pièces. Pour qu’un boulon fabriqué dans une usine puisse être assemblé avec un écrou produit ailleurs, il faut définir des dimensions, des matériaux et des tolérances identiques. La normalisation devient alors une condition indispensable du développement industriel.

Au début du XXᵉ siècle, cette logique franchit une étape décisive avec Frederick W. Taylor. Dans The Principles of Scientific Management (1911), il défend l’idée qu’à chaque tâche correspond une « one best way », une méthode objectivement plus efficace que toutes les autres. Le rôle de l’organisation consiste alors à observer le travail, mesurer les gestes, éliminer les variations individuelles et imposer la meilleure procédure.

Cette vision marquera durablement le management moderne.

Après la Seconde Guerre mondiale, la normalisation ne concerne plus seulement les produits mais également les organisations elles-mêmes. Les démarches qualité, les référentiels ISO puis les travaux d’Henry Mintzberg sur les mécanismes de coordination renforcent l’idée que la performance repose sur des processus clairement définis, documentés et reproductibles.

Avec l’informatisation des entreprises dans les années 1980 et 1990, cette logique trouve un prolongement naturel dans les systèmes d’information. Les ERP, les logiciels métiers et les outils de Business Process Management (BPM) promettent d’implémenter directement les « bonnes pratiques » sous forme de workflows.

Progressivement s’impose alors une représentation implicite du fonctionnement des organisations.

Le modèle implicite du management moderne

Pour beaucoup de décideurs, la création d’un processus suit naturellement quatre étapes.

1. Un besoin métier apparaît.
2. Des experts identifient la meilleure façon d’y répondre.
3. Un éditeur transforme cette bonne pratique en logiciel.
4. L’organisation déploie ce logiciel et améliore ses performances.

La grande force de ce modèle est qu’il simplifie un monde complexe. Il laisse penser que la performance dépend essentiellement de la qualité des outils achetés, et il fournit une réponse rassurante à chaque nouveau besoin :

« Cherchons le logiciel qui implémente la bonne pratique. »

Dans les domaines fortement réglementés, ce raisonnement fonctionne effectivement très bien.

La comptabilité en est un excellent exemple : les règles d’enregistrement y sont définies par la loi, les référentiels comptables sont largement stabilisés (PCG, IFRS…) et les écarts sont facilement identifiables. Dans ce contexte, un logiciel peut implémenter une très grande partie de la « bonne pratique ». De plus, comme toute erreur représente potentiellement un coût élevé pour l’organisation, les conditions de marché sont favorables à la commercialisation d’un outil dédié.

Il en va de même pour la paie : le droit social, la fiscalité et les conventions collectives encadrent fortement les calculs. Les marges d’interprétation sont limitées ; il est donc rationnel de produire un logiciel standard capable de répondre aux besoins des d’entreprises.

Dans ces situations, la standardisation crée effectivement de la valeur.

Pour autant, ces situations constituent-elles la règle ?

Le point aveugle du modèle

Posons-nous une question simple : existe-t-il une seule bonne manière de lancer un nouveau produit ? Une seule bonne façon d’intégrer une entreprise après une acquisition ? De de gérer un client stratégique ? De piloter une transformation numérique ou de coordonner plusieurs directions lors d’une crise ?

La réponse est évidemment non, parce que ces activités ne sont pas uniquement techniques : elles reposent sur des arbitrages permanents entre des contraintes parfois contradictoires : objectifs économiques, réglementation, contraintes techniques, rapports de pouvoir, culture de l’entreprise et compétences disponibles.

Autrement dit, le processus n’existe pas avant l’organisation : il est construit progressivement par les femmes et les hommes qui travaillent ensemble. Chaque décision, chaque exception, chaque compromis modifie légèrement la manière de travailler.

C’est précisément cette réalité que les ergonomes décrivent depuis plusieurs décennies à travers la distinction entre travail prescrit et travail réel.

Comme l’explique Lucy Suchman dans Plans and Situated Actions, les procédures ne déterminent jamais entièrement l’action. Elles constituent des ressources sur lesquelles les acteurs s’appuient, mais qu’ils interprètent et adaptent continuellement pour faire face aux aléas qui caractérisent toute organisation.

Cette capacité d’adaptation ne concerne pas seulement les individus ; elle transforme progressivement les processus eux-mêmes. Dans un article devenu une référence en théorie des organisations, Martha S. Feldman et Brian T. Pentland montrent qu’une routine organisationnelle possède toujours deux dimensions complémentaires : une dimension ostensive, qui correspond à la procédure telle qu’elle est décrite, enseignée ou représentée, et une dimension performative, qui correspond à la manière dont les acteurs la mettent effectivement en œuvre dans les situations concrètes. Or cette dimension performative n’est jamais une simple exécution mécanique de la procédure : elle est faite d’ajustements, d’arbitrages, d’improvisations et d’apprentissages. À chaque exécution, la routine est donc susceptible d’évoluer. Les processus métiers ne sont pas des objets figés que les organisations appliquent fidèlement ; ce sont des constructions vivantes que les acteurs recréent et transforment continuellement.

Cas d’école de création d’un processus métier

Voici une anecdote tirée d’un cas réel, et qui illustre la naissance d’un processus métier.

Dans un groupe industriel, le comité exécutif décide de suivre les initiatives de décarbonation lancées par les usines.

Jusqu’à présent, chaque site pilote ses projets localement : récupération de chaleur, remplacement d’équipements, optimisation des consommations, nouveaux emballages… Aucune application ne recense ces initiatives, car personne n’avait jamais eu besoin de les consolider mais aujourd’hui, le comité exécutif réclame la mise en place d’un reporting trimestriel.

Une dizaine de responsables se réunissent et très vite, les divergences d’objectifs sont manifestes : la direction RSE veut mesurer les tonnes de CO₂ évitées, alors que la direction industrielle préfère suivre les économies d’énergie. La finance souhaite connaître les investissements réalisés et les gains attendus tandis que les responsables d’usine rappellent qu’ils ne disposent pas tous des mêmes données.

Rapidement, des questions apparemment simples deviennent source de débats :

Faut-il déclarer uniquement les projets terminés ou également ceux en cours ?

Comment traiter un projet qui réduit la consommation d’énergie mais augmente les déchets ?

Et finalement, qu’appelle-t-on exactement une « initiative de décarbonation » ?

Après plusieurs réunions, le groupe s’accorde sur une première version du processus.

Ce n’est pas le meilleur processus possible, personne n’a obtenu exactement ce qu’il souhaitait, mais c’est le meilleur processus que ces experts ont réussi à construire ensemble, compte tenu de leurs contraintes respectives.

La naissance d’un processus métier ressemble presque toujours à cette scène.

Contrairement à une idée largement répandue, les processus ne sont pas découverts comme des lois naturelles. Ils sont construits progressivement par des experts qui cherchent à concilier des objectifs différents : conformité réglementaire, efficacité opérationnelle, maîtrise des risques, qualité de service ou rentabilité.

Cette idée rejoint les travaux d’Herbert Simon sur la rationalité limitée. Dans Administrative Behavior (1947), Simon montre que les décideurs ne recherchent pas une solution optimale au sens absolu ; ils s’arrêtent généralement sur une solution satisfaisante (satisficing), compatible avec les informations dont ils disposent, les contraintes qu’ils subissent et le temps qui leur est imparti.

Les processus métiers obéissent exactement à cette logique.

Un processus apparaît rarement parce qu’un expert a identifié la « meilleure pratique ». Il naît souvent à la suite d’un incident, d’un audit, d’une évolution réglementaire ou d’une difficulté rencontrée sur le terrain. Plusieurs solutions sont proposées, discutées, abandonnées ou simplifiées jusqu’à ce qu’un compromis acceptable soit trouvé.

Martha Feldman et Brian Pentland dans l’article précédemment mentionné, ont montré que ces compromis ne restent jamais figés : chaque mise en œuvre conduit les acteurs à interpréter, ajuster ou compléter les processus existants, ce qui prépare déjà leur prochaine évolution.

Un processus métier n’est donc pas la traduction fidèle d’une rationalité supérieure : en réalité, il traduit toujours un compromis. Derrière chaque étape d’un workflow, chaque règle de validation ou chaque exception se cache une histoire : un problème rencontré puis un arbitrage patiemment négocié.

Les processus sont l’expression d’une identité organisationnelle

Cette dynamique permet de comprendre pourquoi des organisations évoluant dans le même domaine, de taille comparable, soumis aux mêmes obligations réglementaires et parfois dotés des mêmes outils mettent en place des processus qui peuvent être très différents.

Par exemple, dans une entreprise donnée, les achats sont fortement centralisés : les décisions passent par une direction mondiale qui négocie les contrats cadres. Dans une autre entreprise, les filiales disposent d’une autonomie importante afin de préserver leur agilité locale.

Pourtant, sur le papier, les deux organisations poursuivent le même objectif : acheter mieux.

Ces différences ne sont pas des anomalies, mais la conséquence logique de la manière dont chaque organisation a construit ses propres compromis entre stratégie, contraintes économiques, culture managériale et environnement opérationnel.

Comme l’explique James G. March dans ses travaux sur l’organisation comme système de décision (A Primer on Decision Making: How Decisions Happen, 1994), les organisations ne sont pas des machines optimisant mécaniquement des variables identifiées à l’avance. Elles développent progressivement des façons particulières de décider et d’agir, issues de leur histoire et de leur apprentissage collectif.

Un processus métier est donc toujours situé : il porte la trace de l’entreprise qui l’a construit.

La singularité des processus peut devenir un avantage concurrentiel

Dans une culture managériale largement influencée par la recherche de « bonnes pratiques », la différence entre organisations est souvent considérée comme un problème à corriger. Pourtant, certaines différences constituent précisément une source de performance.

Les travaux de David Teece sur les dynamic capabilities (Dynamic Capabilities and Strategic Management, 1997) montrent que l’avantage concurrentiel ne repose pas uniquement sur la possession de ressources particulières, mais sur la capacité d’une organisation à reconfigurer rapidement ses ressources et ses pratiques lorsque son environnement change.

Une entreprise qui sait adapter ses processus plus rapidement que ses concurrents possède donc un avantage stratégique. Cela explique pourquoi certaines organisations excellent dans des domaines où aucun logiciel standard ne peut fournir une réponse universelle : lancement de nouveaux produits, relation client complexe, ou transformation organisationnelle. Leur avantage provient justement de leur capacité à construire un processus adapté à leur contexte.

Quand la standardisation des processus métiers devient contre-productive

Si les processus sont des compromis construits par les organisations, on comprend mieux pourquoi l’importation d’une « bonne pratique » extérieure peut parfois produire des résultats inattendus.

Le problème n’est généralement pas le logiciel lui-même. Les grandes solutions de gestion reposent sur des décennies d’expérience, intègrent des pratiques éprouvées et créent une valeur considérable dans les domaines où les processus sont suffisamment stabilisés.

En revanche, le risque apparaît lorsque l’organisation considère que le processus encodé dans l’outil constitue une vérité universelle, indépendamment du contexte dans lequel il sera déployé.

L’histoire récente des systèmes d’information offre plusieurs exemples de ce phénomène.

Au début des années 2000, Nike engage un vaste programme de transformation de sa chaîne logistique autour de solutions combinant notamment les technologies de SAP et de i2 Technologies. L’objectif était ambitieux : améliorer la prévision de la demande et optimiser les approvisionnements à l’échelle mondiale.

Le projet rencontre d’importantes difficultés opérationnelles. Une partie du problème vient de la complexité exceptionnelle de la chaîne logistique de Nike : des milliers de références, des cycles de production longs, des fournisseurs répartis dans le monde entier et une forte variabilité de la demande. Les modèles intégrés dans les outils supposaient une capacité de prévision et de synchronisation que l’organisation ne pouvait pas toujours fournir dans la réalité.

Quelques années plus tard, Lidl connaît une situation différente avec son projet eLWIS, lancé pour remplacer un système interne historique par une solution SAP standard. L’ambition était de disposer d’un système intégré capable d’accompagner la croissance internationale du distributeur.

Le projet est finalement abandonné en 2018 après plusieurs années de développement.

L’une des difficultés majeures résidait dans l’écart entre les processus historiques de Lidl et les hypothèses portées par le modèle SAP. Lidl avait construit depuis des années certaines pratiques spécifiques, notamment autour de la valorisation des stocks et de la gestion des prix. Le choix d’un modèle standard impliquait d’abandonner certains fonctionnements qui faisaient partie de l’identité opérationnelle du groupe.

Le problème n’était donc pas simplement technique. Il concernait un désalignement entre un modèle de processus générique et des pratiques organisationnelles construites au fil du temps.

Le cas de Revlon, lors de sa migration ERP en 2016–2018, illustre également ce phénomène. Le déploiement d’un nouvel ERP dans une usine américaine coïncide avec d’importantes perturbations opérationnelles : difficultés de traitement des commandes, retards de livraison et impacts financiers significatifs. Là encore, le projet ne révèle pas une faiblesse intrinsèque des ERP, mais la difficulté de transformer simultanément les systèmes, les processus et les pratiques opérationnelles d’une organisation complexe.

Ces exemples rejoignent les travaux de Wanda Orlikowski sur la « technologie en pratique » (Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations, 2000). Pour Orlikowski, une technologie ne contient jamais à elle seule une manière correcte de travailler. Les usages réels émergent de l’interaction entre l’outil, les pratiques existantes et le contexte organisationnel.

Autrement dit, un logiciel n’impose jamais complètement un processus : il rencontre toujours une organisation qui possède déjà ses propres routines, ses propres compromis et son propre historique.

La standardisation crée de la valeur… dans son domaine de validité

Ces exemples ne signifient pas que les standards ou les logiciels spécialisés sont intrinsèquement néfastes. La standardisation crée une valeur immense dans les activités fortement réglementées, normées, et lorsque les acteurs partagent une définition commune de la bonne manière de travailler.

Dans ces domaines, encoder des pratiques dans un logiciel permet effectivement de réduire les erreurs, d’automatiser les contrôles et de diffuser un référentiel commun.

Mais standardiser un processus implique qu’il puisse être décomposé en tâches élémentaires répétitives et univoques. Or, dans les organisations, de nombreuses activités sont, au contraire, peu répétitives et fortement dépendantes du contexte : on peut penser à la conception de produits, à l’exploration de nouveaux marchés ou encore à la coordination transversale entre entités hétérogène. Ces activités, « résistent » à la standardisation car elles sont avant tout basées sur le jugement, l’essai-erreur, et la négociation.

Par ailleurs, la distinction entre les activités standardisables et celles qui ne le seraient pas ne doit pas être comprise comme une séparation étanche : même dans les domaines les plus normés, une organisation ne se limite jamais aux processus officiellement standardisés.

Autour du cœur transactionnel couvert par les grands systèmes de gestion subsistent de nombreuses activités périphériques : préparation d’analyses, collecte d’informations complémentaires, suivi d’initiatives locales, expérimentation de nouveaux indicateurs ou coordination entre équipes.

Ces activités peuvent sembler secondaires, mais elles jouent souvent un rôle essentiel dans l’évolution de l’organisation. C’est dans ces espaces que les métiers testent de nouvelles façons de travailler, construisent de nouveaux référentiels et préparent parfois les futurs processus standards.

Les travaux de James March sur l’apprentissage organisationnel montrent que toute organisation doit maintenir un équilibre entre l’exploitation des pratiques éprouvées et l’exploration de nouvelles approches. Les outils fortement standardisés répondent efficacement au premier besoin ; ils sont moins adaptés au second.

Ainsi, même lorsqu’une activité principale est parfaitement normée, il existe toujours des zones où l’organisation doit conserver une capacité d’expérimentation et d’adaptation.

Exploiter au mieux les processus métier nécessitera donc de discerner les processus suffisamment mûrs pour être standardisés, et ceux pour lesquels la priorité doit rester la capacité de l’organisation à expérimenter, apprendre et faire évoluer ses propres pratiques.