Le développement sans programmation, aussi appelé No Code, séduit de nombreuses équipes en entreprise. Il permet à des profils non techniques de créer rapidement des outils internes, automatiser des tâches ou concevoir des applications sans faire appel directement à un développeur. Pourtant, malgré ses avantages, le No Code peine à se généraliser dans certaines organisations.
Sécurité des données en entreprise : pourquoi le No Code inquiète
L’un des freins majeurs évoqués par les directions informatiques ou juridiques concerne la protection des informations sensibles. Beaucoup d’outils No Code comme Airtable, Glide ou Make reposent sur des infrastructures cloud, souvent situées hors Europe. Cela peut poser problème pour les entreprises soumises à des réglementations strictes (RGPD, HIPAA, ISO 27001, etc.).
Par exemple, si un collaborateur conçoit une application pour gérer les informations clients avec un outil hébergé aux États-Unis, la question de la souveraineté des données devient cruciale. Le DSI ou le RSSI peut alors refuser son déploiement sans validation complète de la conformité du service.
Autre point sensible : les autorisations d’accès. Un outil mal configuré peut exposer des données confidentielles à des utilisateurs non autorisés. Sans supervision centralisée, il devient difficile de garantir que les règles d’accès sont correctement appliquées.
Points de vigilance à prendre en compte :
- Où sont hébergées les données (pays, fournisseurs, type de stockage)
- Quelle est la politique de chiffrement et de sauvegarde
- Quel niveau de traçabilité est offert (logs, historique des actions)
- Comment sont gérés les rôles et permissions utilisateur
Comment atténuer ce blocage :
Mettre en place une charte interne pour encadrer l’usage de ces outils, valider à l’avance une liste de plateformes compatibles avec les exigences de l’entreprise, et former les utilisateurs à la gestion des accès et des données.
Fiabilité des projets No Code sur la durée : les doutes des équipes IT
Même dans les structures prêtes à tester de nouveaux outils, le No Code fait souvent face à un manque de confiance sur la robustesse des projets à long terme. L’équipe IT peut craindre qu’une application construite sans normes de développement claires finisse par devenir difficile à maintenir, à mettre à jour ou à connecter aux systèmes existants.
Autre inquiétude fréquente : la dépendance totale à une plateforme. Par exemple, si l’entreprise mise tout sur Bubble, que se passe-t-il si l’abonnement devient trop cher ou que le service ferme soudainement ? Contrairement aux projets codés en interne, les solutions No Code reposent sur des interfaces propriétaires, souvent peu exportables.
De plus, chaque utilisateur construit selon sa propre logique, ce qui rend les outils plus difficiles à reprendre par un autre collaborateur. Cela crée une dette organisationnelle invisible, où la documentation est rarement faite et où les projets deviennent rapidement incompréhensibles.
Risques concrets évoqués par les DSI :
- Verrouillage sur une seule solution (pas d’accès au code source)
- Modifications aléatoires ou non testées faites par des non-techniciens
- Outils disparates et peu cohérents entre équipes
Que faire pour fiabiliser les projets No Code ?
Mettre en place des modèles standardisés (modèles d’apps, process validés), désigner un référent interne pour accompagner les projets et imposer une documentation minimale avant chaque mise en production.
A LIRE AUSSI Comment créer un agenda familial partagé sur Google en moins de 5 minutes?
Culture interne et résistance au changement organisationnel
L’autre blocage souvent négligé est humain et organisationnel. Le No Code remet en cause certains équilibres historiques entre les services métiers et les équipes techniques. Il donne le pouvoir de créer directement aux équipes opérationnelles, sans passer par le service informatique, ce qui peut créer des tensions ou des incompréhensions.
Dans les structures hiérarchiques classiques, le développement reste souvent centralisé. Lorsque des profils non développeurs se mettent à créer leurs propres outils, cela peut être vu comme une intrusion ou une perte de contrôle.
Autre problème : certains managers craignent de perdre en visibilité sur les outils utilisés dans leur périmètre. Une application développée sans validation peut générer des résultats incohérents, ou ne pas respecter les règles internes.
Exemples de freins organisationnels :
- Perception que seuls les développeurs peuvent produire des outils fiables
- Difficulté à gérer la multiplicité des outils créés en dehors de la DSI
- Crainte d’une « jungle d’initiatives » sans supervision
Comment débloquer ce frein culturel ?
Il faut intégrer le No Code dans une démarche de transformation plus large. Former les managers, valoriser les réussites internes (création d’un CRM simplifié, d’un outil de reporting, etc.), et créer des passerelles entre les métiers et l’IT pour que ces initiatives soient vues comme complémentaires et non concurrentes.
