Introduction

Dans le quatrième volet, nous avons constaté que les actifs qui n’ont jamais été codés sont voués à devenir les dettes du futur. Revenons donc à la question centrale : le développement citoyen est-il un moyen de produire un système de production ?

La réponse est non. Sa raison d’être réside dans un « développement brouillon » qui matérialise les exigences du point de vue utilisateur.

Si l’on confond cette idée avec « le développement citoyen est une baguette magique que tout le monde peut utiliser », on répétera l’histoire : on produira de nouvelles dettes comme à l’ère de Kami Excel. Examinons donc ce que signifie ce « développement brouillon » et comment l’exploiter intelligemment.

Série complète

Quelle est la valeur d’un développement brouillon ?

Les applications construites par les équipes terrain via le développement citoyen sont parfois jugées « incomplètes » ou « brutes ». Mais c’est précisément cette rugosité qui fait leur valeur.

Les exigences vues par les utilisateurs ressortent

Imaginez une équipe commerciale qui crée une application de gestion client en low-code. Elle y injecte l’intuition du quotidien : « il faut cela sinon c’est inutilisable ».

  • Le niveau de détail des champs de saisie
  • Ce qu’il faut voir dans les listes
  • L’emplacement naturel des boutons et des parcours

Tout cela ne passe pas dans un simple cahier des charges. Décrire les spécifications en texte n’offre jamais la nuance ou le « ressenti terrain ». Avec un prototype qui fonctionne, on obtient une réaction sincère : « oui, ça marche » ou « non, c’est pénible ».

Les erreurs et oublis ressortent tôt

Avec un brouillon en fonctionnement, il devient plus facile de découvrir que : « il manque une recherche ici » ou « le circuit d’approbation doit avoir deux niveaux, pas trois ».

Dans de nombreux projets, des experts lisaient un cahier des charges et concevaient le système « à l’imagination ». À la livraison, l’écart avec les attentes déclenchait frustrations et retours en arrière. Le développement citoyen peut couper court à ce cycle stérile.

Les pièges de la mise en production

Pourtant, il ne faut jamais transformer ce brouillon tel quel en production. Les pièges sont nombreux.

  • Scalabilité : un outil fonctionne dans un petit service mais sature immédiatement lorsqu’il est déployé à l’échelle de l’entreprise.
  • Sécurité : contrôles d’accès et journalisation sont trop légers, impossibles à auditer ou à certifier.
  • Maintenabilité : l’outil devient dépendant d’une personne ; dès qu’elle quitte le poste, tout redevient une boîte noire.

Autrement dit, « le brouillon est utile » ne veut pas dire « le brouillon peut devenir la version finale ». C’est exactement le piège qui a transformé Kami Excel en dette : sauveur temporaire, passif à long terme.

Partage des rôles avec les spécialistes

Comment faut-il traiter le produit du développement citoyen ? La réponse est limpide.

  • Les citoyens dessinent le brouillon : ils concrétisent le ressenti utilisateur et fournissent un prototype vivant.
  • Les spécialistes le réécrivent : ils reconstruisent en respectant les exigences non fonctionnelles (scalabilité, sécurité, maintenabilité).

Cette répartition maximise les forces de chacun. Les citoyens traduisent la « sensation du terrain » directement dans l’outil. Les spécialistes garantissent la qualité et la pérennité en produisant la version finale.

Dans les approches classiques, on concevait sur la base d’un cahier des charges approximatif. Avec un brouillon fonctionnel, la discussion démarre dès le départ avec un niveau de précision élevé. Résultat : développement plus efficace et meilleure qualité.

Ce que la gouvernance doit encadrer

Pour tirer parti du développement citoyen, il faut des règles organisationnelles.

  • Clarifier : stipuler que les artefacts citoyens restent des prototypes à périmètre limité.
  • Inventorier : mettre en place un processus de tri et de suppression régulière des apps ou RPA abandonnés.
  • Organiser la passation : lorsqu’un brouillon est utile, l’IT doit le reprendre, le réécrire et le mener jusqu’à la production.

Avec une telle gouvernance, on réduit fortement le risque de reproduire les dettes de l’ère Kami Excel. Sans ces garde-fous, le développement citoyen se transforme en usine à « applications sauvages » et n’augmente que la dette technique.

Synthèse

Le développement citoyen n’est pas une méthode pour que n’importe qui bâtisse un système de production. Mais en tant que « brouillon », il réduit les malentendus dans la définition des exigences et permet d’intégrer pleinement le point de vue des utilisateurs.

La production appartient aux spécialistes ; le brouillon, aux citoyens. En appliquant cette séparation, le développement citoyen devient un tremplin vers la productivité plutôt qu’une dette.

Sa véritable signification réside dans un processus de définition des exigences démocratisé. Avec cette compréhension, il peut devenir une force durable pour l’organisation.

Prochain article : Les angles morts qui fabriquent des dettes en série 6/7