Je crois au « maker », pas au mythe du « citizen » (sans gouvernance)

Je vais être très clair, parce que c’est un sujet où le flou coûte cher: je ne “crois pas” au développement citoyen en tant que modèle d’exploitation. Pas parce que les utilisateurs seraient incapables de construire quelque chose, non, bien au contraire, mais parce qu’un logiciel ne se résume pas à “le faire marcher aujourd’hui”. Un logiciel, c’est le faire tenir debout dans le temps, sous pression, avec des données qui grossissent, des gens qui changent de poste, des règles de conformité qui s’appliquent, et une organisation qui finit toujours par dire: « c’est critique pour le métier ».

Mon point de friction n’est donc pas la capacité du développeur citoyen. C’est la responsabilité: qui supporte, qui documente, qui corrige, qui sécurise, qui fait évoluer, qui répond quand ça casse à 8h42 un lundi matin.

1) Développement citoyen: de quoi parle-t-on, exactement ?

On mélange tout le temps trois choses:

1. Low-code / no-code: c’est une approche technique (des outils qui permettent de construire avec peu/pas de code). (microsoft.com)
2. Développement citoyen: c’est un modèle opérationnel (des personnes hors IT construisent des apps/automatisations). (ResearchGate)
3. Gouvernance: c’est le système immunitaire de la plateforme (règles, garde-fous, conformité, visibilité, cycle de vie). (Microsoft Learn)

Le Project Management Institute positionne le citoyen comme quelqu’un qui peut créer des applications avec des plateformes low/no-code, sans dépendre entièrement de l’IT. (Project Management Institute)
C’est séduisant. Ça promet de réduire le backlog, d’augmenter l’agilité, d’impliquer les métiers. Très bien. Mais dans la vraie vie, une promesse n’est pas un plan d’exploitation.

2) Pourquoi je suis allergique au terme « citoyen »

Je viens d’un passif que beaucoup d’organisations ont vécu: l’âge d’or (puis l’âge sombre) des fichiers Excel et ses macros et des bases Access “maison”.

Le schéma est presque toujours le même:

• Au début: un utilisateur brillant règle un vrai problème métier, vite, mieux que personne.
• Ensuite: il partage. Ça devient utile. Puis populaire. Puis “indispensable”.
• Enfin: ça s’intègre dans un processus. Et là… ça devient un système.

Et les systèmes ont une propriété physique: ils accumulent de la dette.

Ce n’est pas une opinion isolée: la littérature sur l’“end-user computing” et les feuilles de calcul documente depuis longtemps la fréquence des erreurs et le risque organisationnel quand les artefacts deviennent critiques sans contrôles d’ingénierie.

Le point important ici n’est pas “les utilisateurs font n’importe quoi”. Le point, c’est que l’outil et le contexte n’imposent pas:

• tests,
• traçabilité,
• revue,
• documentation de décisions,
• séparation des environnements,
• stratégie de données,
• gestion du cycle de vie.

Donc on finit par fabriquer… ce qu’on a déjà fabriqué avec Access: des applications qui existent, mais qui ne sont supportées par personne.

3) Je crois au “citizen build”, pas au “citizen run”

La croyance naïve, c’est: « si quelqu’un peut construire, il peut supporter ».
La réalité, c’est: build ≠ run ≠ change.

• Build: produire une solution qui marche “dans mon contexte”.
• Run: l’exploiter de façon fiable (incidents, accès, continuité).
• Change: la faire évoluer sans casser (versioning, régressions, déploiements).

Le développement citoyen est excellent pour le build rapide.
Il est structurellement mauvais pour le run et le change… sans cadre.

Et ce n’est pas un jugement moral. C’est juste que le métier de “supporter” une application n’est pas le métier d’un RH, d’un comptable, d’un directeur de service ou d’un stagiaire.

4) Les zones que le citoyen ne peut pas “deviner”

4.1 La donnée

Le premier sujet qu’un vrai développement doit traiter, c’est: où vivent les données, et avec quelles garanties.

Un utilisateur peut parfaitement faire une app Power Apps sur une liste SharePoint. Et parfois c’est acceptable. Mais dès qu’on parle de:

• relations complexes,
• intégrité référentielle,
• règles de sécurité fines,
• volumes qui montent,
• exigences de performance,
• on quitte le monde “tableur amélioré” pour entrer dans le monde “système de données”.

Microsoft documente explicitement les différences entre Lists et Dataverse (capacité, types de données, modèle relationnel, considérations au-delà de certains volumes). (Microsoft Learn)
Et Microsoft rappelle aussi que SharePoint n’offre pas nativement l’intégrité référentielle d’un système relationnel — ce qui a des conséquences directes sur la qualité des données quand l’app devient sérieuse. (microsoft.com)

Donc quand on demande à un citoyen de “faire l’app”, on lui demande implicitement de décider:

• schéma,
• normalisation,
• stratégie d’historique,
• règles d’accès,
• conventions de données,
• évolutivité.

Si on le forme à ça… on en fait déjà un développeur. Et on sort du slogan “citizen”.

4.2 Le cycle de vie (ALM)

Le deuxième sujet, c’est l’ALM (Application Lifecycle Management): comment on versionne, comment on déploie, comment on fait dev/test/prod.

La Power Platform pousse précisément une approche basée sur:

• solutions,
• variables d’environnement,
• références de connexion,
• pipelines,
• pour rendre l’ALM praticable même dans un monde low-code. (Microsoft Learn)

Et Microsoft positionne les pipelines comme un moyen de réduire la complexité ALM pour makers/admins/devs, ce qui, en creux, reconnaît un fait : sans ALM, ça ne scale pas. (Microsoft Learn)

Or, le citoyen développeur typique:

• développe dans le “bon” environnement (souvent le mauvais),
• fait des modifications “en live”,
• n’a pas de notion claire de packaging,
• et ne sait pas ce que coûte un déploiement “propre”.

Résultat: quand l’IT récupère, il doit reconstruire la compréhension avant même de reconstruire la solution. Et c’est là que tu te retrouves avec ton fameux: “5-6 jours pour comprendre… autant que pour refaire”.

4.3 La gouvernance

Le développement citoyen n’est pas un problème tant qu’il reste dans un bac à sable. Le problème commence quand il touche:

• des données sensibles,
• des connecteurs risqués,
• des processus critiques,
• des identités personnelles.

C’est exactement pour ça que Microsoft insiste sur:

• une stratégie d’environnements,
• des politiques DLP (Data Loss Prevention),
• des bonnes pratiques d’administration pour protéger les actifs et soutenir l’ALM. (Microsoft Learn)

Et côté “visibilité”, le CoE Starter Kit est précisément conçu pour aider à inventorier, suivre l’usage, et mettre en place des composants de gouvernance et de nurture. (Microsoft Learn) mais je recommande au organisation de développer leur propres outils de gouvernance car ils ne doivent souvent pas se limiter seulement aux plateformes de Microsoft et doivent surtout permettre la stabilité nécessaire au pilotage et au pilotage stratégique de l’organisation.

Sans ces mécanismes, tu recrées du shadow IT, même si l’outil est “officiel”. D’ailleurs, les autorités de cybersécurité rappellent que le shadow IT, c’est d’abord un problème d’usage non encadré, pas un problème d’outils.

4.4 Identité et propriété

Là, on arrive à un point que j’adore (ironie) parce qu’il est ultra concret: les automatisations.

Un flow Power Automate “personnel” est souvent lié:

• au compte du créateur,
• à ses connexions,
• à ses permissions.

Microsoft documente le phénomène des orphaned flows: quand le propriétaire quitte l’organisation (ou perd une identité valide) et qu’il n’y a pas de co-propriétaire, le flow peut devenir orphelin et commencer à échouer, notamment si les connexions nécessitent authentification. (Microsoft Learn)

Microsoft documente aussi:

• comment partager un flow et ajouter des owners/co-owners,
• comment changer le propriétaire,
• et le support des flows détenus par un service principal pour éviter la dépendance à une personne physique.

Donc quand je dis “le citoyen ne peut pas supporter”, ça se traduit en clair par:
si ton automatisation repose sur ton identité personnelle, elle est déjà en sursis.

5) La documentation

Ici, je vais être un peu brutal: les commentaires ne remplacent pas la documentation. Et même une IA qui “explique le code” ne pourra pas deviner proprement les raisons d’un choix.

La documentation utile, c’est le “pourquoi”:

• Pourquoi Dataverse plutôt que liste SharePoint ?
• Pourquoi cette règle métier ici ?
• Pourquoi cette structure de données ?
• Pourquoi cette exception ?
• Pourquoi ce contournement ?

Dans le monde logiciel, il existe un outil simple et léger pour capturer ça: les Architecture Decision Records (ADR), popularisés et largement recommandés comme moyen d’écrire le contexte, la décision, les alternatives, et les conséquences. (martinfowler.com)

Et c’est exactement ce qui manque dans 95% des apps citoyennes: pas la “doc marketing”, mais la mémoire des décisions. Sans ça, l’équipe qui récupère refait les mêmes débats, les mêmes tests, les mêmes erreurs. Encore. Et encore.

6) Le vrai modèle qui marche

Je ne suis pas anti-citoyen. Je suis anti-illusion.

Microsoft ne pousse pas seulement “citizen development”. Microsoft pousse très clairement la fusion development: faire travailler ensemble devs pro et makers, avec une culture et des pratiques qui partagent l’ownership et la qualité. (Microsoft Learn)

Et là, je suis d’accord.

Le citoyen est excellent pour:

• clarifier le besoin,
• prototyper,
• prouver la valeur,
• itérer vite sur l’UX métier.

Le pro/IT est indispensable pour:

• industrialiser la donnée,
• sécuriser,
• rendre déployable,
• rendre observable,
• rendre maintenable.

7) Ma position, formulée comme un contrat de gouvernance

Voici la version “opérationnelle” de ma position. Pas un slogan. Un contrat.

Règle 1: Toute app/automatisation a une catégorie de criticité

Tu classes dès le départ:

• Personnel (moi-même)
• Équipe (mon service)
• Département (plusieurs équipes)
• Entreprise (processus critique / données sensibles)

Et chaque catégorie déclenche un niveau de contrôle.

Règle 2: Au-delà du “Personnel”, tu sors du freestyle

À partir du moment où c’est partagé et que ça devient process, tu exiges:

• un second propriétaire (co-owner),
• une stratégie d’identité (service principal quand possible),
• une base de doc minimale (voir plus bas).

Règle 3: Stratégie d’environnements + DLP obligatoires

Tu ne fais pas de “vraie” solution dans un environnement non maîtrisé.

• environnements alignés ALM,
• DLP par environnement,
• connecteurs autorisés / bloqués selon le risque.

Règle 4: Les solutions Power Platform ne vivent pas “hors solutions”

Dès que ça dépasse l’expérimentation: tu passes en solution (packaging), tu utilises variables d’environnement et références de connexion pour déployer proprement. (Microsoft Learn)

Règle 5: La donnée considérée sérieusement

Lists/SharePoint, oui, pour certains usages. Mais pas comme réflexe universel.
Tu t’appuies sur la matrice de choix officielle (Lists vs Dataverse for Teams vs Dataverse) et tu assumes les limites. (Microsoft Learn)

Règle 6: “Support” n’est pas un hobby

Tu définis un modèle:

• support niveau 0/1 (métier): usage,
• support niveau 2 (plateforme): incidents techniques,
• support niveau 3 (évolution): backlog produit.

Sans ça, tu crées un goulot… sur la personne qui a construit.

Règle 7: Documentation minimale

Minimum vital:

• objectif et périmètre,
• utilisateurs & droits,
• sources de données,
• dépendances,
• scénarios de panne connus,
• et 3 ADR max: les décisions structurantes. (AWS Documentation)

Règle 8: Handover

Le citoyen livre un MVP validé. Ensuite, si l’app “passe en production”, elle change de statut:

• reprise par une équipe fusion/IT,
• durcissement (sécurité, données, ALM),
• mise sous gouvernance complète.

Règle 9: Observabilité

Tu mets en place l’inventaire et le suivi (CoE Starter Kit ou équivalent), sinon tu voles à vue. (Microsoft Learn)

Règle 10: Former le citoyen… sans le transformer en développeur pro

Tu ne peux pas exiger d’un citoyen:

• architecture,
• sécurité,
• ALM,
• review,
• performance,
• tout seul.

Par contre tu peux lui donner:

• des patterns,
• des templates,
• des garde-fous,
• un chemin de graduation,
• et une équipe de référence.

8) La phrase qui résume tout

Le développement citoyen “pur”, tu construis, tu déploies, tu supportes, tu documentes, tu sécurises, tu fais évoluer, n’existe pas à l’échelle d’une organisation sérieuse. A part peut-être les organisation dont le métier et le modèle économique est de produire des applications.

Ce qui existe, et qui fonctionne, c’est:

• du prototypage métier (rapide, utile, proche du besoin),
• dans une plateforme gouvernée (environnements, DLP, visibilité),
• avec un mécanisme clair de graduation/handover,
• et une culture fusion (métier + IT) plutôt qu’une religion du “self-service”. (Microsoft Learn)

Le reste, c’est un remake d’Access… mais avec une interface plus jolie et des connecteurs premium.

Je ne veux pas tuer l’élan. Je veux éviter l’accident industriel

Je comprends parfaitement l’attrait du développement citoyen: il libère, il accélère, il rend visible l’intelligence métier. Et oui, un utilisateur est souvent la meilleure personne pour écrire une user story… parce qu’il la vit.

Mais je refuse de vendre l’idée que “construire” suffit.

Un système sans gouvernance est un incident en attente.
Et le jour où ça devient critique, l’organisation paie deux fois: une fois pour l’avoir laissé naître sans cadre, et une deuxième fois pour le réindustrialiser en urgence — en perdant du temps à comprendre ce qui n’a pas été documenté.

Moi, je ne suis pas anti-citoyen.
Je suis pro-responsabilité.

Et c’est exactement ce que la gouvernance est censée garantir: qu’une bonne idée ne devienne pas une bombe à retardement.