Automatisation des processus : quelle alternative au BPMN ?

Par Ronan Bertel, CEO DAMAaas

Digitalisation des processus : des alternatives sérieuses au BPMN?

Les applications no code ont le vent en poupe en matière d’automatisation des processus en entreprise. L’approche trouverait néanmoins ses limites pour gérer des processus plus élaborés, au point que certains acteurs de l’IT en appellent à l’utilisation du BPMN pour développer leurs applications no code. Au-delà du paradoxe qui consiste à ramener de la complexité là où il n’y en avait plus, l’approche est finalement peu adaptée pour répondre aux besoins des métiers.

Une entreprise se définit par ses processus et ces derniers sont d’ailleurs au cœur de la norme ISO9001. Dans un souci de gain de performance, nombreuses sont les organisations qui ont entamé la transformation numérique de leurs processus métier. La pandémie n’a fait qu’amplifier le phénomène. D’ailleurs les structures les plus avancées en la matière sont souvent celles qui ont le mieux résisté à la crise et aux besoins de réorganisation du travail et de la collaboration.

Les processus sont par essence transverses. Ils s’appuient sur différentes plateformes (sites web, agences, portails, apps…), différents systèmes d’information (CRM, ERP…), de nombreuses règles métier et nécessitent de fait pour les dématérialiser et les automatiser le développement d’applications spécifiques.

Le no code au service du BPM et inversement

Pour engager concrètement cette transformation, deux approches sont le plus couramment privilégiées. L’approche BPM (Business Process Management) est la plus historique : elle désigne à la fois une méthode de modélisation de processus métier, adossée à l’usage d’un progiciel adapté. En parallèle, le no-code connaît depuis quelques mois un fort succès. Il renvoie à une approche modulaire du développement de logiciels : dans l’esprit, les utilisateurs construisent une application à partir d’une liste de composants réutilisables.

Actuellement, 8 entreprises sur 10 utilisent une plateforme no code pour mettre à disposition des applications métiers. La tendance a explosé : elles étaient 44% en 2020, elles ont aujourd’hui atteint la barre des 80% (Source : Gartner / Forrester 2019). Dans les faits, le no code et le BPM se rejoignent souvent. Les organisations y font appel non seulement pour créer une application mais aussi pour codifier un processus spécifique dans le cadre d’une initiative BPM plus large.

Le BPMN, adapté aux processus complexes…

En informatique comme ailleurs, toute médaille a son revers. Ainsi, certains acteurs de l’IT pointent du doigt les applications no code qui ne seraient pas en capacité d’exécuter les processus les plus complexes de l’entreprise. Et l’on voit certains éditeurs de logiciel faire le choix de la norme BPMN et intégrer ce langage à leur plateforme pour répondre aux besoins les plus élaborés de leurs clients. Le BPMN serait plus approprié pour traiter de la complexité. Il proposerait aussi des systèmes davantage compatibles avec d’autres applications, facilement interopérables…

En tant que spécialiste du BPM, mon point de vue est tout autre. Posons le décor d’abord. La norme BPMN , ou Business Process Management Notation, a été conçue il y a presque vingt ans par un consortium d’acteurs internationaux représentatifs des leaders du marché du BPM. C’est une norme de notation internationale, reconnue ISO depuis 2013, conçue pour définir et dessiner de manière standardisée les processus. La philosophie de l’outil visait à donner un référentiel commun et accessible au plus grand nombre pour modéliser les processus métier, simplifier la communication entre les fonctions métiers et les informaticiens et développer avec rigueur et efficacité des applications souhaitées.

… mais dé-corrélé de l’expression des besoins et du terrain

Dans les faits, l’usage du BPMN est lui aussi… complexe ! C’est un langage graphique qui nécessite un certain temps d’appropriation pour être capable de jongler entre les objets de flux, les objets de relation, les couloirs et les objets symboliques et d’utiliser à bon escient une centaine d’objets graphiques différents. Au-delà du vocabulaire et de la syntaxe propre à ce langage, c’est surtout son “rapport au monde” et son approche de la modélisation qui nous semblent insatisfaisants et d’une certaine manière limitants.

La philosophie du BPMN repose sur une description très précise des processus de l’entreprise. Cette dernière s’élabore de manière décorrélée des données. Elle décortique les modalités d’un “comment” sans interagir réellement avec l’objet des actions réalisées et les acteurs concernés. Un peu comme si, en langage culinaire, on décrivait l’enchaînement des étapes d’une recette de cuisine sans s’intéresser aux ingrédients et leurs implications en termes de goût, de texture et aux compétences des cuisiniers…
Le BPMN se centre et décrit de manière très détaillée les enchaînements d’un processus. Il ne s’intéresse pas aux interlocuteurs ou aux données concernées par les actions. Or, c’est la clé d’entrée des acteurs métiers. De ce point de vue, la norme BPMN peut représenter un frein au déploiement autonome d’un workflow métier et suppose souvent l’appui de la DSI pour aboutir.

Process driven et data driven : même combat

Partant de ce constat, de nombreux acteurs ont développé une approche non plus “process driven”, à l’instar du BPMN mais plutôt “data driven” (Data Driven Architecture) centrée donc sur la donnée. Ainsi, la modélisation du processus s’effectue dans son environnement concret : l’entrée se réalise par les data qui tirent ensuite le workflow et la construction du processus. Et pas le contraire !

A titre personnel, je suis convaincu par la capacité du no code à gérer des processus métiers complexes, pour autant qu’on lui adjoigne des outils de workflows adaptés. Pour le concevoir, il n’y a pas lieu de choisir entre une approche centrée processus, type BPMN, et une approche orientée data. Des solutions existent pour réconcilier les deux mondes et ne garder de chacun que ce qui crée de la valeur pour les utilisateurs.

La conception d’une application, de toute typologie d’outils, doit partir du terrain et s’envisager à travers des éléments aussi concrets que les étapes, les actions, les acteurs mobilisés que l’on renseigne ensuite facilement dans des valeurs de liste, tâche, bouton ou date. Ces fondations posées, la notion de processus peut entrer en ligne de compte, avec ses droits d’accès et ses règles de fonctionnement…

Avec l’approche “data process driven”, la facilité de conception prime : c’est la condition sine qua non pour que les métiers s’approprient la démarche et le résultat qui en est issu : l’application. Le service est ainsi rendu par le système d’information qui intègre un applicatif construit par et pour les métiers. L’outil est réplicable dans d’autres services, auprès d’autres équipes, au plus près des attentes… La DSI de son côté voit sa charge de travail réduite, tout en gardant le contrôle de l’application s’il le souhaite. La sécurité – dans et autour de l’application – est évidemment assurée, son intégration au SI existant garantie, le shadow IT écarté. Une ultime question subsiste alors : pourquoi faire simple quand on peut faire compliqué?

• Ronan Bertel en bref

Ronan Bertel est le fondateur et CEO d’INAGUA, société éditrice de DAMAaaS, solution no-code de création d’applications de BPM (Business Process Management). Informaticien de formation, après 20 ans de parcours dans l’informatique bancaire chez Paribas puis au Crédit Agricole, il touche aussi aux fonctions d’organisation et de management de la distribution des mêmes réseaux bancaires. Côté technique ou côté management, c’est bien le manque d’outil de gestion qui l’a amené à innover. Il a imaginé avec Nicolas Thery, associé chez Inagua, une boîte à outils no-code permettant d’apporter en quelques heures une réponse personnalisée aux besoins des métiers.

Garant de la cohérence fonctionnelle de DAMAaaS, Ronan en est également le « Product Owner » et pilote depuis 2011 la roadmap. Portant les valeurs du pragmatisme et de l’agilité, il est enfin le manager des équipes de consultants technico fonctionnel d’INAGUA qui interviennent auprès des clients pour la co-création de leurs applications.