Low-code et no-code en B2B : gouverner sans interdire.

Les plateformes de développement visuel permettent à des profils métier de construire des applications et des automatisations sans écrire de code. Elles répondent à une demande réelle, celle de directions qui attendent depuis des mois un développement que la DSI ne peut pas prioriser. Elles produisent aussi une informatique parallèle dont personne ne connaît le périmètre, et qui devient un problème le jour où une application construite par un métier tombe en production. Cette page traite les deux questions qui décident du cadre, dans le prolongement de notre couverture IA, données et plateformes.

Ce que ces plateformes changent réellement

Définition. Une plateforme low-code permet de construire une application par assemblage visuel de composants, avec une possibilité d’extension par du code. Une plateforme no-code s’en tient à la configuration visuelle sans écriture de code. La frontière est commerciale plus que technique, les deux catégories convergeant.

Le déplacement n’est pas technologique, il est organisationnel. Ce qui change, c’est qui décide de construire une application, et qui en répond ensuite.

Trois usages dominent en entreprise, avec des profils de risque très différents :

• L’automatisation de tâches personnelles ou d’équipe. Rapprochement de fichiers, notifications, formulaires internes. Risque faible, bénéfice réel et immédiat.
• Les applications métier départementales. Suivi d’activité, gestion de demandes, référentiels locaux. Risque moyen, qui devient élevé dès que l’application est utilisée par d’autres services.
• Les processus engageants. Traitement de commandes, calculs financiers, données clients. Risque élevé, et c’est là que la gouvernance doit trancher.

Les deux questions qui décident du cadre

Elles sont plus déterminantes que le choix de la plateforme.

Qui répond de l’application quand elle tombe ? Une automatisation construite par un métier qui interrompt une chaîne de commande un vendredi soir devient un incident de production. Si personne n’a été désigné responsable, l’appel arrive à la DSI, qui découvre simultanément l’existence de l’application, sa logique et son périmètre.

Que se passe-t-il quand son auteur quitte l’organisation ? C’est le scénario le plus fréquent et le moins anticipé. Une application non documentée, construite par une personne partie, continue de tourner jusqu’à ce qu’elle casse. Plus personne ne sait alors ce qu’elle fait ni pourquoi.

Ces deux questions se traitent avant le déploiement, pas après le premier incident. Elles conditionnent le cadre bien davantage que les fonctionnalités de la plateforme retenue.

Le cadre qui fonctionne

Ni l’interdiction, qui déplace l’usage vers des outils encore moins visibles, ni le laisser-faire, qui produit une informatique parallèle non recensée.

La ligne décisive est le seuil de bascule. Il doit reposer sur des critères objectifs : nombre d’utilisateurs, nature des données traitées, caractère engageant du processus, intégration à un système de production. Un seuil défini à l’avance transforme une reprise en main en procédure prévue, plutôt qu’en conflit à chaud.

Le raccordement au socle d’authentification est le premier chantier technique. Une application construite hors DSI qui gère ses propres comptes crée des accès qui survivent au départ de leurs titulaires. Voir notre couverture de la gestion des identités et des accès.

L’IA change l’échelle du sujet

Les plateformes intègrent désormais des fonctions d’intelligence artificielle générative, ce qui déplace le problème sur deux points.

La vitesse de production. Décrire un besoin en langage naturel et obtenir une automatisation fonctionnelle réduit le délai de création à quelques minutes. Le volume d’applications non recensées croît d’autant plus vite.

La qualification réglementaire. Une automatisation construite par un métier qui intègre une fonction d’IA entre dans le périmètre du règlement européen, avec les obligations de transparence en vigueur depuis le 2 août 2026 et, selon l’usage, une qualification au regard des annexes. Ces applications doivent figurer dans l’inventaire des systèmes d’IA décrit dans notre section gouvernance IA et AI Act.

C’est le point que les directions informatiques mesurent mal : l’inventaire des systèmes d’IA ne peut pas ignorer ce que les métiers construisent eux-mêmes.

Explorer le cluster

Cette page fait partie de notre couverture de l’intelligence artificielle, de la donnée et des plateformes : gouvernance, socle technique et industrialisation.

iTPro+ : recevez chaque semaine les analyses applicatives et de gouvernance qui concernent les directions informatiques.