No-code : pourquoi les DSI ont plus à gagner qu’à perdre

Low code no code development platform concept. Programmer using laptop, showing digital puzzle pieces connecting software modules, drag and drop app coding, application for rapid solution building

Article co-écrit avec Christophe PINARD, partenaire de Mews Partners.

Les directions informatiques connaissent bien cette tension qui émaille leur quotidien : des métiers qui attendent des outils presque immédiatement, des carnets de demandes saturés, et des équipes IT rarement dimensionnées pour tout absorber. Dans ce contexte, le no-code est parfois lu comme un contournement de l’IT. Vu de plus près, il ouvre surtout une question plus profonde : comment organiser l’autonomie des métiers sans perdre la maîtrise du système d’information ?

Des outils conçus plus près des usages

Dans beaucoup d’organisations, les délais acceptables ne sont plus les mêmes. Un outil qui arrive trois mois trop tard finit souvent contourné, remplacé par un fichier Excel ou abandonné avant même d’avoir été déployé. Les équipes terrain veulent pouvoir corriger un irritant opérationnel au moment où il apparaît, pas trois cycles budgétaires plus tard.

C’est dans ce contexte que les plateformes no-code ont trouvé leur place. PowerApps, Tulip ou Anaplan ont dépassé le registre de l’interface simplifiée pour non-développeurs. Leur intérêt tient désormais à leur capacité à épouser les usages terrain, à se personnaliser finement et à s’intégrer aux systèmes existants via des APIs.

Les cas d’usage apparaissent souvent sur des sujets très quotidiens : un suivi de performance en logistique, quelques reportings finance automatisés, un rituel d’animation de production digitalisé. Autant de besoins réels, parfois modestes, qui justifiaient difficilement le lancement d’un projet IT complet.

Ce mouvement s’est aussi accéléré pour une raison structurelle. Les nouvelles générations qui rejoignent les entreprises ont grandi avec des outils intuitifs et arrivent avec une appétence réelle pour exploiter ces plateformes. Le point de départ n’est plus le même : l’usage d’interfaces digitales fait partie de leur environnement naturel, même si l’appropriation des règles métier, des données et des contraintes de l’entreprise reste indispensable.

Pour les directions informatiques, le sujet se déplace donc. Il ne s’agit plus seulement de livrer plus vite, mais d’organiser une capacité de développement distribuée dans l’entreprise.

De l’outil local à la brique intégrée

Dans les ateliers, les entrepôts ou les fonctions support, cette bascule est déjà visible. Un goulot d’étranglement à objectiver, un lead-time à comprendre, une performance d’atelier à suivre au quotidien : ces besoins n’ont rien de théorique. Une équipe peut désormais prototyper, puis dans certains cas mettre en production, un outil dédié en quelques heures ou quelques jours. Collecte de données, visualisation, analyse, connexion aux processus existants : le cycle se raccourcit fortement, sans nécessairement lancer un projet IT complet ni passer par un long processus de spécification.

ERP, document management concept.Businessman working with laptop

Le gain de vitesse ne doit toutefois pas être confondu avec une disparition des exigences d’architecture, de sécurité ou de cycle de vie applicatif. Une partie de la conception est prise en charge par les métiers, mais les contraintes d’un système d’information maîtrisé demeurent.

Plusieurs évolutions techniques expliquent cette bascule. La première tient à la maturité des interfaces de développement. Le glisser-déposer n’est plus que la partie visible du sujet. Les plateformes actuelles permettent de connecter les applications métier aux systèmes existants, ERP, bases de données, capteurs ou automates, via des APIs, avec une souplesse d’intégration qui était jusqu’ici réservée aux équipes techniques.

L’intégration IT/OT, longtemps complexe, devient également plus accessible grâce à des architectures fondées sur des protocoles comme MQTT et des plateformes capables de centraliser les données issues des machines et des équipements de terrain. L’enjeu consiste désormais à faire dialoguer interfaces locales, briques applicatives, données industrielles et systèmes d’entreprise dans un ensemble cohérent.

L’arrivée de l’IA générative dans ces environnements accentue encore le mouvement. La génération de code, la création d’agents ou la composition de workflows complexes s’intègrent peu à peu dans l’expérience utilisateur de ces plateformes. Des équipes opérationnelles peuvent désormais concevoir des prototypes avancés, automatiser des workflows ou enrichir des applications existantes avec un niveau d’autonomie qui aurait encore récemment nécessité l’intervention d’équipes techniques.

Les utilisateurs gagnent ainsi une marge de manœuvre inédite sur la manière dont leurs outils se construisent et évoluent. Ce déplacement oblige les directions informatiques à clarifier ce qui fait encore leur contribution spécifique lorsque les demandes applicatives simples ne passent plus toutes par elles.

La DSI libérée d’une partie du flux, pas de ses responsabilités

Le premier effet pour la DSI se mesure très vite dans le flux de demandes. Les développements simples ou très spécifiques, qui mobilisaient des ressources importantes pour une valeur créée parfois limitée, peuvent être progressivement absorbés par les équipes métier. Ce déplacement peut redonner de la disponibilité aux équipes IT sur les sujets où leur expertise reste déterminante : architecture, sécurité, intégration des systèmes critiques, gouvernance de la donnée.

L’effet se joue aussi du côté de l’adoption. Quand les utilisateurs co-conçoivent leurs outils, les solutions correspondent davantage aux besoins du terrain. Les allers-retours diminuent, les corrections se font en continu, et l’appropriation suit plus naturellement. Les sponsors métier, souvent en première ligne sur le change management, voient aussi leur rôle facilité. Pour la direction informatique, cela se traduit par moins de retours en développement, moins de frictions au déploiement et des solutions plus susceptibles de tenir dans la durée.

Pour la DSI, le mouvement peut alors changer la nature de la relation avec les métiers. Moins sollicitée sur l’exécution de demandes simples, elle peut davantage peser sur les standards, l’intégrité des systèmes et les choix d’architecture.

Man, developer and help with coding on computer screen in office for testing web application or troubleshooting. Programming, staff and employee with advice on developing software solution at startup

Encore faut-il traiter les risques dès le départ.

Lorsque chaque équipe définit ses propres structures, la cohérence de la donnée se fragilise : les référentiels divergent, les rapports ne se recoupent plus, et les décisions se prennent sur des bases fragiles. Très vite, le sujet dépasse la technique et touche à la qualité même du pilotage managérial, car deux directions peuvent croire suivre le même indicateur alors qu’elles ne parlent plus exactement de la même chose.

L’intégrité de l’ERP et des systèmes critiques impose aussi une vigilance particulière. Dans un écosystème de plus en plus interconnecté via des APIs, chaque point de connexion doit rester sécurisé, audité et maîtrisé. La DSI reste responsable de la protection du socle sur lequel reposent les opérations de l’entreprise.

Le foisonnement applicatif exige la même attention. Il progresse souvent sans bruit, au fil des initiatives locales. Sans visibilité sur ce qui tourne réellement dans l’organisation, les applications redondantes s’accumulent, les responsabilités deviennent floues, les droits d’accès ne sont pas toujours révisés, et la valeur se dilue dans une complexité que plus personne ne maîtrise réellement.

Dans la plupart des cas, ces dérives apparaissent lorsque la gouvernance arrive après les usages, au lieu de les accompagner dès le départ. La manière dont la DSI s’organise face à cette nouvelle donne va donc déterminer une large part de la valeur réellement créée.

Organiser l’autonomie sans perdre la maîtrise

Face à l’autonomie croissante des métiers, beaucoup de DSI oscillent entre deux réflexes : reprendre la main sur les initiatives ou laisser les usages se développer librement.

Une centralisation complète préserve la cohérence et les standards, mais elle recrée vite les lenteurs que le no-code devait précisément réduire : demandes empilées dans une équipe centrale, arbitrages tardifs, solutions conçues loin de leurs utilisateurs. L’agilité, pourtant recherchée, disparaît alors dans l’engorgement.

À l’inverse, une autonomie totale favorise l’expérimentation et accélère les premiers résultats. Les solutions émergent vite, l’appropriation est naturelle, les itérations suivent les besoins réels. Jusqu’au moment où personne ne sait plus ce qui tourne dans l’organisation, où les données divergent selon l’outil consulté, et où la cybersécurité devient une préoccupation traitée trop tard.

Le modèle Hub & Spoke apporte une réponse pragmatique à cette tension. Dans cette organisation, la DSI définit le cadre commun : gouvernance, standards d’architecture, règles de sécurité, droits d’accès, homologation des connecteurs et maîtrise des données critiques. Les équipes métier, les Spokes, construisent, expérimentent et font évoluer certains outils au plus près des usages.

Les métiers disposent ainsi d’un espace d’action plus large, mais dans un cadre défini par la DSI, notamment sur les données, les risques et l’architecture globale.

Certaines plateformes no-code avancées ont déjà structuré leur écosystème autour de cette logique. Anaplan, particulièrement mature sur ce point, en offre une illustration concrète : son approche de centre d’excellence combine une cellule centrale qui tient le cadre et des référents métiers habilités qui développent et font évoluer les solutions au plus près du terrain.

Reste que l’organisation ne suffit pas si les règles de fonctionnement demeurent implicites. Une gouvernance explicite, un catalogue des applications existantes et une communauté interne de bonnes pratiques constituent le socle minimal. À cela s’ajoute une clarification des règles du jeu : quels cas d’usage peuvent être traités en autonomie par les métiers, quels accès aux données sont autorisés, quels composants doivent être réutilisés, quels contrôles sont nécessaires avant mise en production, et comment les applications seront maintenues, auditées ou retirées dans le temps.

Bien conçu, le centre d’excellence donne à l’agilité les conditions de sa durée. Sa vocation consiste moins à reprendre chaque initiative qu’à organiser une autonomie maîtrisée : suffisamment ouverte pour accélérer les métiers, suffisamment structurée pour protéger les données, les processus critiques et l’architecture d’ensemble.

Le nouveau contrat entre DSI et métiers

Aucune plateforme ne prendra en charge ce qui relève encore de la direction informatique : la cohérence du système d’information global, la robustesse des processus critiques et la maîtrise des risques associés.

Dans les organisations qui ont pris le sujet en main, la question de l’adoption est déjà largement dépassée. Le débat porte désormais sur le périmètre d’autonomie accordé aux métiers, les règles associées et l’articulation avec le système d’information global.

Le rôle de la DSI se redessine précisément à cet endroit. Son intervention ne consiste plus à absorber toutes les demandes applicatives, ni à laisser les initiatives locales se multiplier sans cadre. Elle consiste à installer une autonomie métier réellement gouvernée, en concentrant l’expertise IT sur les systèmes régaliens, la sécurité des données, la gouvernance des interfaces et l’intégrité des processus critiques.

Le choix des plateformes comptera. Mais la manière dont la DSI décide de se positionner dans cet écosystème pèsera davantage sur la valeur réellement créée.

Dans les organisations qui ont fait ce travail, gouverner l’autonomie des métiers s’est révélé plus structurant que de la contenir.

Article rédigé par :