Tribune : Les applications no code ont le vent en poupe. Et l’utilisation du BPMN pour développer leurs applications no code serait une solution. Elle est peu adaptée pour répondre aux besoins des métiers assure cependant Ronan Bertel, CEO de DAMAaas.

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é ?

Source : ZDNet.com