Le « Citizen development » connaîtra-t-il le même sort que le moteur hybride ?

Vous allez immédiatement vous demandez ce qui m’a piqué quand le compare la notion de « citizen development » avec un véhicule hybride !

D’ailleurs, qu’est-ce que signifie ce terme barbare: « citizen development » ? En effectuant quelques recherches, on trouve rapidement une définition du Gartner qui le définit comme:

A citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT

Gartner

Pour faire concis et tenter une rapide traduction française l’idée est de permettre à un utilisateur métier de créer ses propres outils informatiques à partir de moyens fournis par son service informatique. Chaque utilisateur deviendrait pourrait devenir un développeur d’application ou de processus.

Alors, rêve, fantasme ou réalité à portée de clics ?

Citizen Developer

Disons le: on est clairement dans la tendance du marché qui pourrait laisser entendre que chacun peut – sans aucune formation ou presque – tout réaliser à partir de son environnement. N’est-ce pas d’ailleurs la promesse éternelle de l’informatisation ? Néanmoins, la réalité est toute autre, et si on se laisse emporter par ce doux rêve – sans doute prématuré -, la désillusion risque de se trouver au bout du couloir. L’idée est bonne bien sur, la tendance est là ! Mais tous les ingrédients du succès ne sont pas si évidents.

Bien sûr, les éditeurs proposent des solutions de plus en plus simple a implémenter. On parler de plus en plus de solutions low-code/no-code qui font dorénavant légion chez la plupart des éditeurs de logiciels. Mais est-ce suffisant pour prétendre transformer nos utilisateurs métier en créateur d’application/processus? D’ailleurs, ces derniers ont-ils vraiment envie de devenir des “citizens developers” ?

A la première question mon constat est plutôt mitigé. Bien sûr, les solutions no-code permettent à nos utilisateurs de réaliser leurs processus. Mieux encore, des éditeurs créent des assistants évolués voire enregistreurs d’actions afin de simplifier la prise en main de leurs outils par des utilisateurs. Personnellement cela me fait souvent penser à de l’obsolescence programmée … Alors bien sur, ça rend service, mais pour un temps limité. Peut être, celui de se rendre compte que ce que l’on a fait ne peut durer ou tenir une certaine charge. 

Les premières limites du modèle « Citizen Developer »

En prenant ce chemin, on se rend vite compte que si cette démarche n’est pas incluse dans une démarche plus globale de gouvernance: elle est d’ores et déjà vouée à rester isolée ou à l’échec. En effet, si chacun réalise dans son coin et à sa manière un processus … qui alors devient garant de la cohérence globale de ce parc hétérogène de micro-processus fragmentés et parfois incohérents entres eux ? En fait, n’est-on pas en train de recréer une sorte de chaos applicatif (notre bon vieux vieux spaghetti-ware) ?

Vous voyez, si la promesse est belle, la désillusion peut être tout autant proportionnelle. Attention donc aux retours de bâtons d’autant que le début des problèmes n’arrivent pas immédiatement. Le temps de se rendre compte que ces micro-initiatives ont dépassé le cadre du travail individuel. Et ça peut aller vite, très vite !

Alors le “citizen development” bien sur. Mais pas dans un mode anarchique et surtout pas n’importe comment. A mon sens, ce type d’initiative doit rester sous une forme de contrôle. Sans quoi comment déterminer que ce que réalisent nos utilisateurs est cohérent et en phase avec la stratégie globale ? Comment imaginer passer à l’échelle un processus qui a été imaginé par un utilisateur, par lui même et pour lui même ? La limite en matière de liberté et partage du « citizen development » se pose ici. 

Autrement dit: il est difficile d’imaginer une quelconque pérennité dans le “citizen developpement” sans y ajouter une touche de gouvernance et de contrôle.

Un nouveau modèle s’impose

On doit donc imaginer un mode « intermédiaire » dans lequel l’utilisateur métier peut participer et créer ses processus mais tout en laissant un contrôle total aux services informatiques. A y regarder de plus près dans « citizen development » il y a le mot citoyen, ce qui implique donc de fait une notion de cohabitation et de partage entre les utilisateurs: on reste donc cohérent. J’aurais presque envie de dire: « chacun reste à sa place et dans son rôle ». L’utilisateur métier n’est alors aucunement bridé dans sa créativité mais l’exécution reste sous le contrôle de l’informatique.

On s’éloigne donc bien sûr de la dérive potentielle et dangereuse du « citizen developer » avec sa liberté totale de création et d’exécution. On s’inscrit alors dans une autre démarche bien plus pérenne et stratégique. D’ailleurs, on constate souvent que ces démarches (tactiques et strétagiques) peuvent être tout à fait être complémentaires.

Nous avons donc un utilisateur capable de créer ses propres processus tactiques et/ou participer à la création d’application/process standardisés et stratégiques. 

Deux choses me viennent immédiatement à l’esprit.

Premièrement: j’ai envie de dire qu’il serait illusoire de croire qu’une même solution pourrait répondre à ces deux objectifs totalement différents en termes de contraintes, besoins, sécurité et criticité. C’est un point important car naturellement les organisations cherchent à mutualiser ce qui pourrait être semblable. C’est aussi une erreur car l’automatisation intelligente est avant tout un investissement pérenne, basé sur une gouvernance et une stratégie d’entreprise établie.

Deuxièmement je m’interroge sur notre fameux utilisateur métier: Au fond … a-t-il réellement envie de créer ses applications ? 

Du « citizen developer » vers l’employé augmenté

J’en reviens à ma comparaison avec les moteurs hybrides de nos voitures. Notre « citizen development » n’est-il pas en fait la première étape de notre utilisateur métier augmenté ?

En fait, grâce à l’avènement de l’intelligence artificielle, nos utilisateurs n’auront bientôt plus besoin de devenir des citizens developers. Imaginez à la place des enregistreurs capables non plus s’enregistrer bêtement des séquences d’actions mais au lieu de cela de mémoriser  la manière dont travail notre utilisateur pour pouvoir au bout d’un certain temps reproduire une partie de ses actions tout en prenant en compte les particularités et les exceptions qui ont été relevées ?

En ce qui concerne l’automatisation combiné à l’IA, il est évident qu’avec l’arrivée de l’apprentissage auto supervisé (entre autre) nous verrons surgir des assistants encore et toujours plus intelligents. Ils seront même capables de regarder pendant plusieurs jours au-dessus de l’épaule de l’utilisateur pour pouvoir reproduire ensuite une partie de son travail. On verra même que l’automate déterminera seul quelle partie est la mieux à même d’être automatisée et laquelle doit restée réalisée par notre utilisateur.

Voilà pourquoi je comparais en préambule notre « citizen development » à un moteur hybride. Il n’y a aucun sens péjoratif derrière cela mais il me parait évident que ce concept – tout comme le moteur hypbride pour l’automobile – n’est qu’une transition vers la réelle révolution qui transformera concrètement et profondément notre rapport au travail.

On parle en fait et surtout de notre manière d’interagir à l’avenir avec le système d’informations.

Vous savez ce « spaghettiware » qui ne cesse de grossir et se complexifier malgré toutes les initiatives de rationalisations et de standardisation!

En se projetant vers un avenir pas si loin j’aime à imaginer que notre utilisateur n’aura même plus conscience qu’il y a un parc applicatif hétérogène derrière ses assistants numériques ? et cet avenir est vraiment à portée. A vrai dire, c’est plutôt amusant n’est-ce pas d’imaginer que c’est l’IA et non l’humain qui pourrait bien nous masquer pour de bon la complexité de nos propres systèmes informatisés.