Low-code, no-code et shadow engineering : un risque de gouvernance avant d’être un risque de code
Le low-code et le no-code ont déplacé le centre de gravité du développement applicatif vers le métier, mais la gouvernance n’a pas suivi au même rythme. Quand les directions fonctionnelles créent leurs propres applications en quelques jours, le shadow engineering apparaît et la DSI perd la maîtrise du cycle de vie, de la sécurité et des données critiques. Dans ce contexte, la question n’est plus de savoir si le code généré par ces plateformes est « bon », mais si l’entreprise maîtrise encore ses processus, ses applications et ses risques réglementaires.
Les plateformes low-code de type Power Platform, OutSystems ou Mendix promettent un développement applicatif rapide, avec peu de codage manuel et une forte intégration aux services cloud existants. Elles permettent à des utilisateurs avancés de concevoir une application métier sans passer par les développeurs professionnels, en s’appuyant sur des modèles, des connecteurs et des outils visuels de gestion des données. Ce déplacement du pouvoir de conception vers les métiers crée un nouveau type de code utilisateurs, qui échappe souvent aux standards de sécurité, de conformité et de gestion du cycle de vie imposés aux applications d’entreprise classiques.
Le shadow IT n’est plus seulement une feuille Excel connectée à un service cloud, mais un ensemble de plateformes de développement low-code, de micro-applications et de flux automatisés qui manipulent des données sensibles. Dans de nombreuses entreprises, ces solutions se connectent directement aux systèmes de référence via des API, sans revue d’architecture ni validation de la sécurité des données. Le résultat est un maillage d’applications d’entreprise non cartographiées, sans propriétaire clair, sans plan de maintenance et sans stratégie de retour sur investissement mesurable.
Le vrai risque du no-code : l’absence de cycle de vie, pas la qualité technique du code
Pour un directeur technique, le principal danger du low-code et du no-code réside dans l’absence de cycle de vie maîtrisé, bien plus que dans la qualité du code généré. Une application no-code peut être techniquement correcte, mais si personne ne gère les sauvegardes, la sécurité, la maintenance et la conformité, elle devient un point de fragilité systémique pour l’entreprise. Le problème n’est pas que les utilisateurs métiers écrivent du code, mais qu’ils créent des services critiques sans cadre de gestion ni responsabilité explicite.
Dans un environnement maîtrisé, chaque développement applicatif suit un processus structuré, avec revue de code, tests, gestion de configuration et supervision en production. À l’inverse, dans un contexte de shadow engineering, les plateformes de développement visuel permettent de déployer des applications en quelques clics, sans que la DSI ne valide les modèles de données, les règles de sécurité ou l’intégration aux autres applications d’entreprise. Cette absence de gouvernance du cycle de vie transforme des gains de productivité apparents en dette opérationnelle, difficile à résorber lorsque les créateurs initiaux quittent l’organisation.
La conformité réglementaire renforce encore cet enjeu, notamment avec l’AI Act européen (proposition initiale 2021, adoption politique 2023) et les exigences croissantes sur la protection des données et la traçabilité des processus de développement ; à ce titre, un directeur technique devrait analyser l’impact des nouvelles obligations décrites dans l’AI Act sur les DSI pour aligner les plateformes low-code et les applications no-code avec les futures exigences européennes. Quand une application no-code manipule des données personnelles, des données financières ou des données du secteur public, l’absence de documentation, de journalisation et de contrôle d’accès devient un risque juridique direct. La gouvernance des outils low-code et no-code doit donc être pensée comme un sujet de conformité et de gestion des risques, au même titre que les développements traditionnels réalisés par les développeurs professionnels.
Structurer un programme de citizen developers sans perdre le contrôle de la sécurité
Un programme de citizen developers bien conçu transforme le foisonnement d’initiatives low-code et no-code en levier d’innovation encadrée, plutôt qu’en menace pour la sécurité. La clé consiste à offrir des plateformes de développement en mode sandbox, avec des jeux de données anonymisées, des modèles d’applications standardisés et des garde-fous de sécurité intégrés. Dans ce modèle, les utilisateurs métiers peuvent expérimenter librement, mais la mise en production reste sous le contrôle de la DSI et des équipes de sécurité.
Concrètement, la DSI doit définir une plateforme de référence pour les développements low-code, avec un catalogue d’outils approuvés, des connecteurs validés et des politiques de gestion des accès harmonisées. Les environnements de développement, qu’il s’agisse de solutions de type « code low » ou de plateformes plus avancées, doivent être intégrés à l’annuaire d’entreprise, au système de gestion des identités et aux outils de supervision existants, par exemple en s’appuyant sur un standard d’observabilité open source tel qu’OpenTelemetry, dont la maturité est analysée dans une étude détaillée sur l’observabilité open source de référence. Cette intégration permet de suivre le cycle de vie des applications, de détecter les dérives de sécurité et de mesurer le retour sur investissement des initiatives low-code.
La sécurité ne peut pas être externalisée aux seuls outils ; elle doit être intégrée au processus de développement et à la culture des utilisateurs. Un cadre de gouvernance efficace définit des niveaux de criticité des applications, des règles de revue par des développeurs professionnels pour les applications sensibles et des modèles de codage manuel pour les extensions complexes. Dans le secteur public comme dans le privé, cette approche permet de canaliser l’énergie des utilisateurs vers des applications utiles, tout en protégeant les données et en respectant les exigences réglementaires, notamment celles liées à NIS2 (directive européenne 2022/2555) et aux référentiels nationaux de cybersécurité décrits par l’ANSSI dans ses travaux sur la conformité NIS2 en France.
Critères pour migrer une application no-code vers un développement classique
À partir d’un certain seuil de complexité, une application no-code doit basculer vers un développement classique pour rester maîtrisable. Le rôle du directeur technique est de définir des critères explicites de bascule, afin que l’écosystème low-code et no-code ne se transforme pas en enchevêtrement d’outils impossibles à maintenir. Sans ces garde-fous, les plateformes visuelles deviennent des systèmes critiques déguisés, portés par des utilisateurs clés qui ne sont ni formés ni disponibles pour assurer un support de production.
Parmi les critères de bascule, la criticité des données manipulées arrive en tête, notamment lorsque l’application traite des données personnelles sensibles, des données financières consolidées ou des données du secteur public. Viennent ensuite la complexité des règles métier, le nombre d’intégrations avec d’autres services cloud, la volumétrie des utilisateurs et la durée de vie prévue de l’application, qui conditionnent le choix entre une plateforme low-code et un développement applicatif classique. Quand ces seuils sont franchis, la DSI doit reprendre la main, réévaluer l’architecture, envisager un développement d’applications sur mesure et intégrer l’application au portefeuille officiel des applications d’entreprise.
La migration ne signifie pas repartir de zéro, mais capitaliser sur le prototype no-code comme spécification vivante du besoin métier. Les développeurs professionnels peuvent analyser le code généré, identifier les limites du développement automatisé et proposer une architecture plus robuste, en combinant codage manuel, API standardisées et outils de gestion du cycle de vie. Cette approche hybride permet de préserver le retour sur investissement initial du low-code, tout en sécurisant la trajectoire à long terme et en réduisant la dette technique induite par un shadow engineering non maîtrisé.
Transformer le shadow IT en innovation encadrée : un dialogue DG–DSI à structurer
Le recours massif au low-code et au no-code ne peut pas être traité comme un simple problème technique ; c’est un sujet de gouvernance d’entreprise qui implique directement la direction générale. Quand 87 % des organisations performantes estiment devoir prendre plus de risques sur les technologies émergentes, selon Gartner (enquête 2023 sur les priorités des CIO, « 2023 CIO and Technology Executive Survey », Gartner, 2023), la question n’est pas de bloquer les plateformes low-code, mais de décider quels risques sont acceptables et sous quelles conditions. Le directeur technique doit donc porter un discours clair auprès du DG sur l’équilibre entre innovation rapide, sécurité des données et conformité réglementaire.
Ce dialogue doit s’appuyer sur des indicateurs concrets, comme le nombre d’applications créées hors DSI, la proportion d’applications critiques hébergées sur des services cloud non référencés ou le volume de données sensibles exposées via des connecteurs non validés. En cartographiant les plateformes de développement low-code, les environnements de « code citoyen » et les applications d’entreprise issues du shadow engineering, la DSI peut objectiver le risque et proposer un plan de régularisation progressif. Ce plan inclut la mise en place d’un catalogue de solutions approuvées, la formation des utilisateurs clés et l’intégration systématique des nouvelles applications au référentiel de gestion du cycle de vie.
Pour la direction générale, l’enjeu est de transformer un shadow IT subi en innovation encadrée, en alignant les objectifs métiers avec les capacités des développeurs professionnels et des équipes de sécurité. Un cadre de gouvernance clair définit qui peut créer quelles applications, sur quelle plateforme, avec quels outils et selon quel processus de développement, en distinguant les prototypes à courte durée de vie des systèmes structurants. Cette approche renforce la confiance entre métiers et DSI, réduit les risques de non-conformité et maximise le retour sur investissement des initiatives low-code et no-code, tout en préservant la souveraineté de l’entreprise sur ses données et ses processus.
Architecture, observabilité et conformité : industrialiser le low-code sans étouffer l’agilité
Industrialiser le low-code et le no-code suppose de traiter ces applications comme des composants à part entière de l’architecture d’entreprise. Cela implique de les intégrer aux référentiels d’urbanisation, aux pipelines de déploiement, aux outils d’observabilité et aux processus de gestion des incidents, au même titre que les développements classiques. Sans cette intégration, les plateformes low-code restent des silos opaques, difficiles à superviser et impossibles à auditer de bout en bout.
Sur le plan technique, la DSI doit définir des patterns d’architecture réutilisables pour les plateformes de développement low-code, en imposant par exemple le passage systématique par une API gateway pour accéder aux systèmes de référence. Les services cloud utilisés par ces plateformes doivent être intégrés aux solutions d’observabilité existantes, en s’appuyant sur des standards comme OpenTelemetry, afin de corréler les événements issus des applications low-code avec ceux des systèmes back-end. Cette approche permet de détecter plus rapidement les incidents, d’identifier les applications responsables et de mesurer l’impact réel des solutions low-code sur la performance globale du système d’information.
Sur le plan réglementaire, la montée en puissance de cadres comme NIS2, le RGPD (applicable depuis 2018) et l’AI Act impose une traçabilité accrue des processus de développement, des accès aux données et des décisions automatisées. Les plateformes de développement low-code doivent donc être configurées pour produire des journaux d’audit complets, documenter les flux de données et faciliter les revues de conformité, en s’alignant sur les recommandations nationales et européennes en matière de cybersécurité. Pour un directeur technique, l’enjeu est de concevoir une architecture de gouvernance qui rende le low-code et le no-code compatibles avec ces exigences, sans sacrifier la vitesse d’exécution ni la capacité d’innovation des métiers.
Chiffres clés sur le low-code, le no-code et le shadow engineering
- Selon Gartner, le marché mondial des plateformes low-code a dépassé les 20 milliards de dollars en 2023, avec une croissance annuelle supérieure à 20 %, ce qui reflète l’adoption massive de ces solutions par les entreprises de tous secteurs (prévisions de marché low-code Gartner 2023, rapport « Forecast Analysis: Low-Code Development Technologies, Worldwide », Gartner, 2023).
- Gartner estime également que plus de 70 % des nouvelles applications développées par les entreprises utiliseront des technologies low-code ou no-code à l’horizon 2025, ce qui renforce l’urgence d’une gouvernance adaptée pour éviter la prolifération incontrôlée d’applications critiques (Gartner, prévisions 2021–2025 sur le développement applicatif, étude « Predicts 2021: Low-Code Development Technologies », Gartner, 2021).
- Une étude de Forrester publiée en 2022 indique que les organisations ayant structuré un programme de citizen developers réduisent de 30 à 50 % le temps de mise sur le marché de certaines applications métier, tout en maintenant un niveau de sécurité comparable aux développements classiques (Forrester, « The State of Low-Code Platforms », Forrester Research, 2022).
- Selon une enquête de l’ISACA de 2021 sur le shadow IT, plus de 40 % des responsables IT déclarent avoir découvert des applications critiques développées hors DSI, souvent sans documentation ni plan de continuité, illustrant l’ampleur du shadow engineering dans les grandes organisations (ISACA, rapport « Shadow IT: Implications for Cybersecurity », 2021).
- Les analyses de McKinsey publiées en 2021 sur l’automatisation et le low-code montrent que les initiatives low-code bien gouvernées peuvent générer un retour sur investissement supérieur à 200 % sur trois ans, grâce à la réduction des coûts de développement et à l’accélération de l’automatisation des processus métier (McKinsey & Company, « Unleashing the power of low-code and no-code », 2021).
FAQ sur le low-code, le no-code et la gouvernance du shadow engineering
Comment un CTO peut-il cartographier le shadow IT lié au low-code et au no-code ?
La première étape consiste à recenser toutes les plateformes low-code et no-code utilisées dans l’entreprise, y compris celles souscrites directement par les métiers via le cloud. Ensuite, il faut analyser les connexions à des sources de données critiques, le nombre d’utilisateurs et la criticité des processus couverts, afin de prioriser les applications à intégrer dans le périmètre de gouvernance. Des outils d’inventaire SaaS et de découverte de flux réseau peuvent aider à identifier les applications non déclarées et à construire une cartographie exploitable.
Pour rendre cette démarche opérationnelle, un CTO peut suivre un mini-plan en cinq étapes : (1) extraire la liste des abonnements SaaS et des licences low-code/no-code actives, (2) croiser ces données avec les journaux d’authentification et les flux réseau, (3) classer chaque application par niveau de criticité métier et type de données manipulées, (4) identifier les propriétaires fonctionnels et techniques, (5) intégrer progressivement les applications prioritaires dans le référentiel officiel du système d’information.
Quels sont les principaux risques de sécurité associés au low-code et au no-code ?
Les risques majeurs concernent l’exposition involontaire de données sensibles, la mauvaise gestion des droits d’accès et l’absence de journalisation des actions des utilisateurs. Les applications créées par des non spécialistes peuvent contourner les politiques de sécurité existantes, par exemple en stockant des données personnelles dans des services cloud non approuvés. Sans intégration aux outils de supervision et de gestion des identités, ces applications deviennent des angles morts pour la DSI et les équipes de sécurité.
Comment décider si une application no-code doit être reprise par la DSI ?
Une application no-code doit être reprise par la DSI lorsqu’elle devient critique pour l’activité, qu’elle manipule des données sensibles ou qu’elle s’intègre à plusieurs systèmes de référence. Des critères objectifs peuvent inclure le nombre d’utilisateurs, l’impact en cas d’indisponibilité, la complexité des règles métier et la durée de vie prévue. Lorsque ces seuils sont atteints, la DSI doit évaluer la faisabilité d’une migration vers un développement classique ou d’une industrialisation sur la plateforme existante.
Le low-code et le no-code menacent-ils les développeurs professionnels ?
Le low-code et le no-code ne remplacent pas les développeurs professionnels, mais déplacent leur rôle vers l’architecture, la gouvernance et l’industrialisation. Les développeurs restent indispensables pour les applications à forte complexité, les intégrations avancées et la sécurisation des systèmes critiques. En pratique, les équipes de développement gagnent en impact en se concentrant sur les fondations techniques, les API et les plateformes, tandis que les métiers prennent en charge une partie de la personnalisation fonctionnelle.
Quelles bonnes pratiques pour lancer un programme de citizen developers en sécurité ?
Un programme de citizen developers doit commencer par la définition d’une plateforme de référence, de jeux de données anonymisées et de modèles d’applications validés par la DSI. Il est essentiel de former les utilisateurs aux notions de sécurité, de protection des données et de cycle de vie applicatif, tout en leur fournissant un support technique minimal. Enfin, la mise en production des applications doit rester sous le contrôle de la DSI, avec des revues systématiques pour les cas d’usage critiques et une intégration aux outils de supervision et de gestion des incidents.