Le citizen development en 2026 : définition, avantages, limites réelles et l’alternative pour les opérations industrielles

Le citizen development est la rébellion du responsable des opérations contre la file d’attente IT. Votre équipe a une idée. L’IT a une file d’attente de six mois. Vous prenez donc une plateforme low-code et vous construisez vous-même. Les premiers projets sont livrés rapidement. Puis la complexité surgit, les intégrations échouent, ou la personne qui a tout construit part et personne ne peut maintenir l’application.

TL;DR

• 🔧 Le citizen development est né d’une vraie douleur liée à la file d’attente IT, et non d’une préférence technologique.
• 📦 Les plateformes low-code accélèrent les formulaires simples et les flux de travail. Elles atteignent un plafond dès qu’une intégration est nécessaire.
• 📉 Les applications créées par des citoyens développeurs deviennent orphelines ou nécessitent une intervention IT lorsque leurs créateurs partent.
• 🚨 Sans supervision IT, le citizen development crée une prolifération d’applications non gouvernées sans piste d’audit.
• ✅ Un logiciel sur-mesure, fait pour vous par des spécialistes et gouverné par l’IT, résout la douleur sous-jacente.
• 💡 L’erreur n’a jamais été « je veux créer un logiciel ». C’était « j’ai besoin d’un logiciel sans attendre six mois ».

Qu’est-ce que le Citizen Development ?

Le citizen development est la pratique par laquelle des employés non techniques créent des logiciels à l’aide de plateformes accessibles. Comprendre ce qui constitue un projet de citizen development et qui entre dans cette catégorie pose les bases pour discuter des cas où cette approche réussit et des cas où elle échoue.

Définition : qui compte comme citizen developer ?

Le citizen development signifie que des employés non techniques créent des applications à l’aide de plateformes low-code ou no-code, sans implication de l’IT. Selon Gartner, un citizen developer est un utilisateur qui crée de nouvelles applications métier destinées à d’autres personnes, en utilisant des environnements de développement et d’exécution approuvés par l’IT de l’entreprise. Cette catégorie est apparue directement d’une réalité : les files d’attente IT sont devenues si longues que les équipes opérationnelles ont cessé d’attendre de l’aide.

Un citizen developer est toute personne sans formation formelle en génie logiciel qui crée des applications, et non des consultants. Pas des développeurs portant des casquettes opérationnelles. La définition originale était plus étroite : uniquement ceux qui utilisent des plateformes approuvées par l’entreprise. Aujourd’hui, la ligne est plus floue. Un répartiteur qui crée un formulaire dans Microsoft Power Apps est un citizen developer. Un responsable de maintenance qui script des automatisations de flux de travail dans Airtable en fait partie. De même pour le directeur des opérations qui a acheté ProcessMaker et l’a connecté à son système de répartition.

La distinction est importante car elle définit le niveau de gouvernance requis. Les plateformes approuvées par l’entreprise sont dotées de pistes d’audit et de capacités de restauration. Les outils non approuvés créent des applications non gouvernées. Le meilleur scénario : une plateforme low-code, la bénédiction de l’entreprise, et quelqu’un pour la maintenir quand le créateur passe à autre chose. Le pire scénario : un flux de travail Zapier construit par un prestataire que personne n’a l’autorisation de modifier.

Comment les plateformes low-code et no-code le rendent possible

Les plateformes low-code (Appian, OutSystems, Mendix, ProcessMaker) et les outils no-code (Airtable, Make, Microsoft Power Apps) ont démocratisé le développement d’applications. Ils ont abaissé le seuil de complexité. Créer un formulaire nécessitait autrefois de recruter un développeur. Désormais, la logique de glisser-déposer et les connecteurs préconfigurés permettent aux équipes opérationnelles de le faire elles-mêmes.

Les plateformes se commercialisent explicitement auprès des opérations. « Construisez sans coder. » « Livrez en jours, pas en mois. » « Donnez du pouvoir à votre équipe. » Le vocabulaire est intentionnel. Elles vendent l’alternative à la file d’attente IT. La proposition de valeur est réelle pour des cas d’usage simples : formulaires, flux d’approbation, tableaux de bord de capture de données. De vraies entreprises livrent de vraies solutions de cette façon. Les plateformes sont véritablement utiles. Le plafond est simplement plus bas que ce que le marketing laisse entendre. Pour un panorama plus large des alternatives proposées par des fournisseurs, voir comment les principales plateformes d’IA agentique pour les opérations industrielles se comparent.

Pourquoi Gartner et Forrester le suivent comme une catégorie

Les cabinets d’analystes suivent le citizen development parce que les responsables IT y investissent à grande échelle. Forrester classe les principales plateformes low-code dans The Forrester Wave, qualifiant la catégorie d’accélérateur significatif de la livraison d’applications pour les cas d’usage auxquels elle est adaptée. Le gain de rapidité est réel pour cette classe de problèmes.

Les plateformes sont également soutenues par des capital-risqueurs et affichent une croissance rapide de leurs revenus, et les analystes suivent les capitaux. Ils suivent aussi la structure des dépenses IT. Quand les départements IT commencent à allouer des budgets au citizen development, c’est une tendance. Gartner et Forrester ne recommandent pas le citizen development comme stratégie. Ils le documentent comme une catégorie et nomment le changement qu’il représente : l’écart croissant entre la demande métier en logiciels et la capacité de l’IT à y répondre.

Pourquoi la file d’attente IT a rendu le citizen development inévitable

La file d’attente IT n’est pas un problème technologique. C’est un problème de capacité. Chaque organisation industrielle accumule des intégrations, rapports, formulaires et demandes de changement en attente qui s’étendent sur des mois. Le citizen development est le symptôme de cet écart insoutenable.

La réalité de la file d’attente dans les organisations industrielles

La plupart des équipes IT industrielles consacrent 70 à 80 % de leur capacité à la maintenance : maintenir SAP en vie, patcher les systèmes AS400 anciens, gérer les mises à niveau de bases de données, corriger les intégrations ERP défaillantes. Les 20 à 30 % restants sont censés couvrir tout ce qui est nouveau : intégrations, rapports, automatisation des flux de travail et visibilité des données, mais ce calcul ne fonctionne pas.

Votre équipe IT maintient 14 systèmes en vie avec quatre personnes, et les nouvelles demandes font la queue. Pendant ce temps, les opérations ne peuvent pas attendre. Une demande typique : « Nous avons besoin d’une vue en temps réel du statut des équipements sur le parc. » La réponse honnête de l’IT : « Six à neuf mois. Nous avons quatre implémentations Maximo devant vous. » La réponse des opérations : « Nous ne pouvons pas attendre six mois. Nous allons le construire nous-mêmes. » Ce n’est pas un choix d’innovation. C’est une situation de prise en otage. Pour une approche directe permettant de réduire la file d’attente IT sans demander aux opérations de créer leurs propres logiciels, voir comment réduire la file d’attente IT dans les opérations industrielles.

Comment les responsables des opérations finissent par créer leurs propres outils

La séquence est prévisible. Un responsable des opérations a une idée qui permettrait de gagner du temps ou de réduire les temps d’arrêt. Il soumet une demande de changement à l’IT. L’IT la met en file d’attente. Six semaines plus tard, il reçoit le message : « Nous pourrons traiter cela au quatrième trimestre 2027. » Il parle à un fournisseur ou découvre une plateforme low-code. Il se dit : nous pouvons construire cela nous-mêmes. Ou il recrute un prestataire pour le construire sur la plateforme low-code.

Le premier pilote réussit. Un formulaire qui prenait une heure à remplir prend désormais deux minutes, et le temps de répartition diminue de 15 %. L’équipe voit immédiatement la valeur. Les responsables des opérations approuvent alors davantage de projets. Même plateforme, même prestataire, même résultat, livraison rapide. L’intuition semble validée. L’organisation commence à croire que le citizen development est la réponse à la paralysie de la file d’attente IT. Ce n’est pas le cas.

Quelles industries adoptent le plus le citizen development ?

Les ports, terminaux et hubs logistiques sont les plus grands adoptants. Ces opérations fonctionnent 24h/24, 7j/7 avec une dette numérique vieille de plusieurs décennies. Un terminal à conteneurs exploitant un TOS des années 1970 avec un tableau de bord de statut maison construit en 2003 n’a pas la capacité d’attendre une modernisation IT. Ils construisent. Les usines de fabrication avec des systèmes ERP anciens et aucune visibilité en temps réel sur l’atelier créent leurs propres applications de statut. Les opérations minières avec des équipements répartis sur des dizaines de sites créent leurs propres tableaux de bord KPI. Les organisations de service sur le terrain créent leurs propres flux de travail de répartition.

Le point commun : une urgence opérationnelle élevée, une dette héritée sur les systèmes, et aucune équipe IT assez grande pour résorber la file d’attente dans un horizon temporel qui compte. Ce sont exactement les industries où l’adoption du citizen development est la plus élevée. Ce sont aussi les industries où les frictions les plus importantes apparaissent lorsque les applications construites par des citoyens développeurs atteignent leur plafond.

Ce que construisent réellement les citizen developers

Les citizen developers commencent généralement petit et valident l’approche sur des problèmes peu complexes. Les formulaires, tableaux de bord, flux d’approbation, suivi du statut des équipements, listes de contrôle de maintenance et rapports KPI manuels sont tous réalisables dans les contraintes du low-code et se livrent rapidement. C’est là que le citizen development fonctionne légitimement.

Quels sont les cas d’usage courants dans les opérations terrain ?

Formulaires remplaçant les registres de quart. Une équipe de maintenance rédige à la main des rapports d’état des équipements dans un registre. Un citizen developer crée un formulaire mobile dans Power Apps ou Airtable. L’équipe coche désormais une liste de contrôle au lieu d’écrire. Les données alimentent un système central. La standardisation est immédiate. C’est une victoire.

Tableaux de bord remplaçant les feuilles de calcul. Un responsable de la répartition crée un tableau de bord Power BI qui extrait des données de plusieurs systèmes sources. Vue d’utilisation en temps réel. Plus besoin de télécharger et de retravailler des feuilles de calcul. Là encore, une amélioration réelle. La plateforme low-code est véritablement utile ici. Pour une analyse approfondie de ce cas d’usage précis, voir le guide sur les rapports automatisés pour les opérations industrielles.

Flux d’approbation remplaçant les e-mails. « Puis-je réserver cet équipement ? » « Cette maintenance peut-elle avoir lieu maintenant ? » Les plateformes low-code rendent trivial le fait de créer un formulaire qui déclenche une notification, recueille une approbation et enregistre la décision. Mieux que les fils d’e-mails.

Capture de statut depuis la radio et WhatsApp. C’est plus délicat mais reste faisable. Un citizen developer intègre une plateforme low-code avec une automatisation Zapier qui écoute un groupe de diffusion WhatsApp. Les pannes d’équipements sont enregistrées automatiquement. Aucune nouvelle application à apprendre pour l’équipe. C’est le plafond où le citizen development devient productif. Pour une approche de niveau production au même problème, voir comment la capture de données agentique transforme WhatsApp, la radio et les e-mails en données opérationnelles structurées.

Les Victoires Rapides Créent une Fausse Confiance

Les cinq premiers projets se livrent rapidement. Les coûts sont faibles. L’adoption est élevée. L’IT n’est pas impliqué, donc il n’y a pas de file d’attente. La direction opérationnelle observe le schéma et approuve de nouveaux projets. “Pourquoi notre système de maintenance des équipements prend-il 18 mois alors que des développeurs citoyens peuvent livrer la capture de statut en trois semaines ?” C’est une question légitime. L’erreur est de croire que la comparaison est valide.

Les premiers projets sont ceux qui correspondent aux contraintes de la plateforme, et les formulaires fonctionnent. Les tableaux de bord fonctionnent, et les workflows simples fonctionnent. Ceux qui sont livrés sont ceux qui peuvent l’être. Le biais de confirmation s’installe. La direction opérationnelle commence à croire que le développement citoyen EST la stratégie IT. Ce n’est pas le cas. C’est la réponse pour une fraction des problèmes, et cette fraction est plus petite que les succès ne le laissent entendre.

Le Piège de la Validation

Après cinq projets de développement citoyen réussis, une organisation conclut souvent : “Le développement citoyen résout notre backlog IT.” C’est le piège. Les projets réussis étaient ceux que les plateformes low-code sont conçues pour traiter. Les projets que le développement citoyen ne peut pas gérer sont toujours dans la file d’attente. Ils sont simplement invisibles parce que personne n’a encore essayé de les construire.

Si un projet nécessite une intégration réelle avec SAP ou Maximo, ou a besoin d’une bibliothèque que la plateforme ne supporte pas, ou implique une logique métier complexe, le plafond se présente. Le projet meurt ou finit par être transmis à l’IT de toute façon, désormais orphelin et portant la dette technique de l’approche développement citoyen.

Là Où le Développement Citoyen Se Heurte à Ses Limites

Les plateformes low-code fonctionnent jusqu’à ce que trois choses se produisent : la logique devient complexe, vous avez besoin d’intégrer des systèmes d’entreprise, ou vous avez besoin d’une bibliothèque que la plateforme ne supporte pas. Dans les opérations industrielles, ces trois situations sont quasi certaines. Le développement citoyen n’est pas une stratégie de mise à l’échelle. C’est un palliatif qui ressemble à une stratégie jusqu’à ce que vous vous heurtiez aux vrais problèmes.

Le Plafond de Complexité

Les plateformes low-code sont optimisées pour une logique simple : si-alors-sinon, calculs de base, routage de workflow, et les plateformes excellent ici. Mais lorsque votre logique implique des algorithmes complexes, des optimisations en plusieurs étapes, ou une intégration avec des bibliothèques spécifiques à un domaine, la plateforme cesse d’être utile. Vous ne pouvez pas construire un prédicteur MTBF dans Power Apps. Vous ne pouvez pas construire un optimiseur de dispatch dynamique dans Airtable. Vous ne pouvez pas implémenter un classificateur d’incidents de sécurité sans coder.

Lorsque le plafond de complexité est atteint, le développeur citoyen a deux choix : simplifier l’idée pour qu’elle corresponde aux contraintes de la plateforme et perdre la valeur du concept original, ou transmettre le projet à l’IT pour le construire dans un vrai langage de programmation, et ce second choix admet l’échec. Le premier livre de la médiocrité. Pour comprendre comment les outils RAD ont évolué au-delà des plateformes low-code, voyez comment le développement rapide d’applications évolue vers des logiciels construits par l’IA.

Les Murs d’Intégration Entreprise

Les opérations industrielles réelles fonctionnent sur des systèmes d’entreprise : SAP, Maximo, MainPac, Navis, AS400. Chaque opération mature dispose d’un système d’enregistrement. Les applications construites par des citoyens qui ne s’intègrent pas à ces systèmes créent des données en parallèle. Les formulaires qui collectent des données sans les synchroniser avec Maximo ne résolvent pas le problème. Ils le dupliquent.

Les plateformes low-code affirment s’intégrer aux systèmes d’entreprise. Elles le font, en surface. Vous pouvez vous connecter à une API Maximo et récupérer des listes d’équipements. Vous pouvez écrire des enregistrements en retour. Mais le vrai travail d’intégration, gérer les incompatibilités de schéma, assurer la cohérence des données, construire des workflows bidirectionnels, gérer les erreurs et les rollbacks, nécessite du code, et du vrai code. Celui que les développeurs citoyens n’écrivent pas.

Un exemple typique : un développeur citoyen crée un formulaire pour saisir les complétions de maintenance préventive. Le formulaire envoie des données à Maximo via une API. Maximo a des exigences de champs différentes. L’intégration échoue la moitié du temps. Le développeur citoyen ne sait pas comment déboguer les réponses API ni écrire la gestion des erreurs. Le projet est transmis à l’IT, qui possède désormais un système construit sans leur participation, sur une plateforme qu’ils ne supportent pas, portant la dette technique de l’approche développement citoyen.

La Charge de Maintenance

Le développeur citoyen qui a construit l’application a un travail principal. C’est un responsable de maintenance, un dispatcher ou un responsable opérationnel, pas un ingénieur. L’application fonctionne jusqu’à ce que quelque chose se casse, et alors qui la maintient ? Si le créateur est toujours là, il pourra peut-être la déboguer. S’il est promu, muté ou quitte l’entreprise, l’application devient orpheline.

L’IT ne souhaite pas adopter des applications de développement citoyen orphelines. On ne les a jamais consultés sur l’architecture. Le codebase ne se trouve pas dans leurs dépôts. La plateforme n’est pas de leur responsabilité. Ainsi, l’application reste en place, accumulant de la dette, et de nouvelles exigences arrivent. Le créateur est parti. L’application échoue ou est abandonnée. C’est un coût réel. Le code qui échappe à la revue IT finit par créer une charge de support pour l’IT de toute façon. Sauf que c’est maintenant une charge sur du code que l’IT n’a pas écrit, dans une plateforme que l’IT ne supporte peut-être pas, sans documentation.

Gouvernance et Sécurité : Le Risque que Crée le Développement Citoyen

Sans gouvernance IT, le développement citoyen crée des applications non gouvernées à grande échelle. C’est là que l’optimisme autour du développement citoyen s’effondre. Les applications non gouvernées représentent un risque technologique invisible et une exposition à la conformité.

Applications Non Gouvernées et Accumulation de Risques

Lorsque le développement citoyen fonctionne sans supervision IT, on obtient un paysage applicatif fragmenté. L’équipe dispatch construit une application de statut dans Power Apps, et la maintenance en construit une dans Airtable. La sécurité en construit une dans un autre outil. Il n’existe pas de registre central. L’IT n’a aucune visibilité sur les applications en cours d’exécution ni sur la manière dont elles accèdent aux données. C’est de l’expansion applicative non gouvernée.

Pour comprendre l’IA non gouvernée et comment elle se propage lorsque les équipes opérationnelles construisent leurs propres outils, voyez à quoi ressemble l’IA fantôme en 2026. C’est un problème de gouvernance, pas un problème technologique. Les équipes opérationnelles ne sont pas malveillantes. Elles essaient de faire leur travail. Mais l’absence de supervision crée des risques. Si l’une de ces applications accède à des données sensibles (localisation des équipements, noms des équipes, dossiers de maintenance), l’IT n’a aucun moyen d’appliquer les permissions ni d’auditer les accès.

Pas de Staging, Pas de Revue, Pas d’Audit

Les logiciels d’entreprise nécessitent un pipeline de revue : environnement de staging, revue de sécurité, évaluation des risques, approbation IT, puis déploiement en production avec des pistes d’audit. Les applications de développement citoyen court-circuitent tout cela. Un responsable de maintenance crée un formulaire, le connecte à Maximo, et il passe en production. Personne n’a testé l’intégration en profondeur. Personne n’a examiné les modifications de schéma. Personne n’a demandé si cela crée un problème de conformité.

Quand quelque chose se casse, il n’y a pas de piste d’audit. Quand quelqu’un accède à des données auxquelles il ne devrait pas, il n’y a pas de journal. Lorsque la conformité réglementaire exige la preuve que seuls des utilisateurs autorisés ont touché des enregistrements sensibles, l’application de développement citoyen ne peut pas le fournir. L’IT assume désormais la responsabilité d’un logiciel qu’elle n’a jamais examiné. Pour un cadre sur la façon dont les responsables IT industriels peuvent gouverner les applications construites par des non-développeurs, voir la gouvernance et la sécurité de l’IA en entreprise pour 2026.

Comment l’IT Hérite de la Charge de Support

Le coût final repose sur l’IT. Un projet de développement citoyen échoue ou crée un incident. L’IT est appelée. Elle doit déboguer du code écrit dans un outil qu’elle n’a pas choisi, par quelqu’un qui n’est pas ingénieur, sans documentation. Elle doit le supporter ou le décommissionner. Dans les deux cas, l’IT en supporte le coût.

C’est pourquoi les responsables IT expérimentés deviennent sceptiques vis-à-vis du développement citoyen. Ce n’est pas de l’élitisme. C’est l’expérience accumulée d’avoir hérité de code non maintenable, construit sous pression temporelle par des non-ingénieurs bien intentionnés. La solution n’est pas d’interdire le développement citoyen. C’est de le gouverner : exiger une revue IT avant le déploiement en production, imposer des environnements de staging, exiger de la documentation, rendre l’IT responsable du processus de revue, et non du backlog IT. Pour comprendre comment gouverner le développement citoyen avec la bonne approche, la solution n’est pas moins de développement citoyen : c’est un développement citoyen gouverné.

Au-Delà du Développement Citoyen

L’idée fondamentale est la suivante : le problème n’a jamais été “je veux construire le logiciel moi-même.” Le problème était “j’ai besoin d’un logiciel fonctionnel sans une file d’attente IT de six mois.” Le développement citoyen est une réponse à ce problème. Ce n’est pas la seule réponse. Ce n’est même pas la meilleure réponse. Il semble simplement l’être parce que c’est le chemin le plus rapide vers une démo.

Le Vrai Problème

Les responsables opérationnels ont des idées, et de bonnes idées. Des idées qui améliorent le débit, réduisent les temps d’arrêt, réduisent les coûts. Ils apportent ces idées à l’IT, et l’IT écoute. L’IT dit : nous avons un backlog de 12 mois. Nous nous en occuperons. Le responsable opérationnel quitte la réunion frustré. Il ne part pas frustré parce que l’IT est obstinée. Il part frustré parce que le backlog IT est réel, et il a du travail à faire la semaine prochaine, pas l’année prochaine.

Le backlog est ici le vrai problème. Le développement citoyen ressemble à la solution parce qu’il contourne le backlog. Mais il ne le résout pas. Il crée un second backlog non gouverné d’applications orphelines. On se retrouve avec deux problèmes au lieu d’un.

Le Logiciel Sur-Mesure Clé en Main Tient les Promesses du Développement Citoyen

Il existe une troisième voie, celle du logiciel sur-mesure clé en main. Les responsables opérationnels décrivent ce dont ils ont besoin. Des spécialistes le construisent dans n’importe quel langage sans plafond de complexité. L’IT le revoit dans un environnement de staging. L’IT l’approuve ou demande des modifications. Ensuite, il passe en production avec des pistes d’audit, une capacité de rollback et le support IT intégré.

Opsima est la fabrique de logiciels IA-native pour les opérations industrielles. Elle construit les logiciels CMMS, TMS, TOS, EAM, ERP, de surveillance d’équipements et de traitement de documents sur lesquels votre exploitation repose réellement, adaptés à la façon dont votre opération fonctionne.

Deux modes de service : (1) adapter votre stack existant (SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) sans rien remplacer, ou (2) construire le logiciel de remplacement quand le système legacy a été dépassé. Livraison en quelques semaines. Vous ne payez que lorsque vous constatez la valeur.

Cette voie conserve l’avantage de rapidité du citizen development (des logiciels fonctionnels en quelques semaines, pas en plusieurs trimestres) sans les risques de gouvernance (code orphelin, absence de pistes d’audit, aucune révision IT). L’exploitation obtient un logiciel professionnel, conçu pour son problème spécifique, sans avoir à apprendre une plateforme low-code ni à dépendre d’un seul développeur pour le maintenir indéfiniment. Pour une comparaison approfondie entre construire, acheter ou confier à un tiers, voir la troisième voie que les responsables des opérations terrain ignorent.

Des logiciels fonctionnels en quelques semaines, approuvés par l’IT

Le résultat est un logiciel fonctionnel, pas une démonstration. Pas une preuve de concept. Un logiciel de qualité production tournant sur vos systèmes existants (SAP, Maximo, Navis, AS400) sans remplacement ni refonte. Un logiciel qui s’intègre à votre infrastructure de données et fonctionne sous gouvernance IT. Pour voir comment l’automatisation des workflows agentiques tient la promesse d’une livraison logicielle rapide et gouvernée, consultez l’automatisation des workflows agentiques pour l’IT industrielle.

Le calendrier se mesure en semaines parce que l’approche est ciblée, sans courbe d’apprentissage d’une plateforme. Aucun citizen developer ne cherche à résoudre des problèmes d’intégration. Des spécialistes expérimentés le construisent, et l’IT le valide. Tout le monde avance. Le backlog commence à se résorber parce que vous disposez d’une capacité qui transforme les exigences en code de production à vitesse élevée.

PNCT (Port Newark Container Terminal) est le cas de référence : +5 % de disponibilité de la flotte, environ 15 % de réduction des pannes non planifiées, et une progression de ~1 000 à ~14 000 changements de statut d’équipements par mois, sans remplacer les systèmes existants.

Conclusion

Le backlog IT dans les opérations industrielles est une contrainte réelle. Les équipes opérationnelles ont besoin de logiciels fonctionnels sans attendre six mois. Le citizen development semble être la réponse parce qu’il livre vite. Mais le citizen development, c’est de la vitesse sans gouvernance. Il crée l’illusion de résoudre le backlog tout en en générant un second, non gouverné.

Si vous êtes directeur de la maintenance ou responsable de la dispatch et que vous gérez cette tension en ce moment, avec des idées que l’IT ne pourra pas traiter avant un an et une pression pour avancer plus vite, l’envie de construire vous-même est rationnelle. L’erreur est de croire que vous pouvez passer cette approche à l’échelle. Pour passer du plafond de complexité du citizen development à un logiciel de production que l’IT gouverne et supporte, réservez une session de travail et découvrez comment le logiciel sur-mesure tient ce que le citizen development avait promis.