Introduction

Dans les deux premiers volets, nous avons montré comment l’EUC et le « Kami Excel » ont, à court terme, sauvé les équipes de terrain tout en léguant des dettes durables à l’organisation. Nous déplaçons désormais le regard vers le présent afin d’examiner les lumières et les ombres des plateformes modernes de développement citoyen, qu’il s’agisse du RPA ou des outils no-code/low-code.

Ces approches rejouent le scénario de Kami Excel tout en chariant des risques encore plus importants en matière d’échelle et de dépendance. Pour analyser l’impact de l’IA générative au prochain épisode, il est indispensable d’en saisir précisément la nature.

Série complète

Lumière — pourquoi ces outils ont-ils été adoptés ?

Résultats immédiats

Sans écrire la moindre ligne de code, quelques manipulations graphiques suffisent pour boucler une automatisation ou une application simple. Remplacer en quelques jours les copier-coller quotidiens ou les tâches répétitives produit un effet immédiat pour les équipes.

La puissance de conviction de la visualisation

Parce que les flux et les écrans prennent la forme de diagrammes visibles, même les publics non spécialistes comprennent rapidement. Pour la direction, voir un « schéma qui fonctionne » procure une grande sérénité et constitue souvent le facteur déclencheur de l’adoption.

Le premier pas des « citoyens »

Tant que l’usage reste limité — formulaires de saisie ou workflows allégés — des non-ingénieurs peuvent créer leurs propres solutions. À ce stade, on ressent effectivement que « tout le monde peut le faire », et cela devient la porte d’entrée pour élargir la base du développement citoyen.

Ombre (1) — le mur professionnel qui apparaît en production

En surface, on pourrait croire que « tout le monde peut s’en servir ». Mais dès que l’on veut l’appliquer sérieusement, il faut raisonner comme en programmation et adopter le regard d’un concepteur de systèmes.

  • L’inévitabilité des structures de contrôle Pour différencier le traitement selon le client, il faut des branches conditionnelles (If/Else). Pour manipuler des centaines d’enregistrements, les boucles (ForEach) sont incontournables. Pour faire face aux lenteurs ou erreurs des systèmes externes, il faut préparer des gestions d’exceptions (Try/Catch). La GUI les rend manipulables, mais il s’agit fondamentalement de programmation.

  • Comprendre les structures de données Déplier des JSON ou des tableaux, mapper les hiérarchies, harmoniser formats de dates et de nombres : ces opérations sont indispensables pour relier les processus métiers. Sans compréhension des structures de données, tout se fissure.

  • La complexité de l’intégration entre systèmes Gérer l’expiration des jetons API, garantir la cohérence entre plusieurs applications, contourner les limites de taux : ce sont exactement les casse-têtes de l’ingénierie logicielle classique, simplement masqués par la GUI.

  • Les exigences d’exploitation et de qualité Surveillance, collecte de logs, gestion des écarts entre environnements de test et de production, plans de retour arrière : sans conception opérationnelle, la confusion arrive vite. Comme rien n’est gouverné par du code versionné, l’observabilité chute facilement.

Face à ce mur, il est difficile pour un développeur citoyen de bâtir et maintenir seul un système taillé pour la production. On finit par dépendre de spécialistes, sans avoir résolu le problème initial de capacité des équipes techniques.

Ombre (2) — verrouillage fournisseur et migrations pénibles

Kami Excel offrait encore une échappatoire : tout tenait dans un fichier. On pouvait exporter les données en CSV, et même si les fonctions ou macros restaient liées à Excel, il existait des tableurs compatibles et la logique demeurait lisible. À l’inverse, les artefacts issus du RPA ou du no-code/low-code se retrouvent enfermés dans des interfaces ou fichiers de configuration propres à chaque plateforme.

  • Migrer vers un autre produit revient pratiquement à tout reconstruire.
  • L’arrêt d’un SaaS ou un changement de spécifications échappent au contrôle de l’utilisateur et peuvent rendre les actifs accumulés caducs du jour au lendemain.
  • Construire sur un PaaS vous enchaîne à l’écosystème du cloud choisi, rendant toute migration extrêmement difficile.
  • Quand la logique est définie via une interface, localiser un point problématique devient laborieux.
  • Selon la conception de l’outil, il faut parfois double-cliquer chaque bloc pour deviner son contenu, ce qui dégrade encore la lisibilité.

Comparé au Kami Excel qui se limitait à un fichier de feuille de calcul, le niveau de dépendance et le risque de dette explosent.

Ombre (3) — le « biais de visualisation » qui rassure trop les dirigeants

Pour les techniciens, il est évident que l’on se heurte vite au « mur professionnel » décrit plus haut. Mais lorsqu’ils voient des flux et des écrans dessinés en GUI, de nombreux dirigeants en concluent que « tout le monde saura s’en servir ».

Pourquoi ? Parce que, pour le management, un système est habituellement une boîte noire. Dès qu’ils aperçoivent des processus reliés par des flèches ou des formulaires alignés, ils ont l’impression de comprendre la complexité interne. En réalité, la même logique de contrôle et les mêmes traitements d’erreurs qu’un programme sont à l’œuvre en coulisse, et il faut des connaissances d’ingénierie pour obtenir un système fiable.

Cet écart entre la « tranquillité d’esprit » des dirigeants et l’inquiétude des techniciens accélère l’adoption tout en nourrissant la dette future.

Vers l’ère du « Kami Excel 2.0 »

Ainsi, RPA et no-code/low-code reproduisent le même schéma que Kami Excel. Ils soulagent rapidement le terrain, convainquent la direction par la visualisation, puis laissent derrière eux un poids en raison de la boîte noire et de la dépendance aux personnes.

La différence décisive tient à l’ampleur de l’impact. Quand Kami Excel se limitait à un fichier isolé, le développement citoyen moderne s’insère dans le cloud ou dans les systèmes de cœur d’activité et peut devenir une dette qui ligote l’organisation entière. Son verrouillage est même plus solide que celui d’Excel : nous voilà face à une version « Kami Excel 2.0 ».

Synthèse

  • RPA et les approches no-code/low-code ont été adoptées grâce à leur rapidité et à la force persuasive de la visualisation.
  • Pour résister à la réalité, il faut maîtriser structures de contrôle, structures de données, intégrations systèmes et conception opérationnelle : un développeur citoyen seul n’y suffit pas.
  • Des interfaces propres à chaque plateforme rendent la migration ardue et renforcent le verrouillage fournisseur.
  • Le « biais de visualisation » des dirigeants sous-estime ces risques et encourage une adoption incontrôlée.

Le développement citoyen moderne est plus puissant que Kami Excel, mais aussi plus précaire. Au prochain épisode, nous verrons ce qui se produit lorsque l’IA générative vient s’ajouter à la donne.

Prochain article : L’influence de l’IA générative sur le développement citoyen 4/7