Low-code / no-code : quelle place dans la stratégie IT ?

Le terrain de jeu naturel du low-code est bien délimité : les applications internes de gestion — suivi de demandes, circuits de validation, tableaux de bord opérationnels — dont la logique est simple et le nombre d'utilisateurs modéré ; l'automatisation de tâches répétitives entre outils existants ; les formulaires et portails simples adossés au système d'information ; et le prototypage, pour confronter une idée à ses utilisateurs avant de décider d'un investissement. Dans ces périmètres, l'avantage est réel et double : la vitesse, et la proximité entre celui qui construit et celui qui connaît le besoin. Une part importante de ces petits outils n'aurait d'ailleurs jamais été développée en approche classique, faute de rentabilité : le low-code résorbe une demande que la DSI ne pouvait pas servir.

Les limites sont tout aussi nettes, et il faut les connaître avant de s'engager. La complexité métier : dès que les règles se densifient, la logique visuelle devient plus difficile à maintenir que du code — sans les outils qui rendent le code maintenable, tests automatisés, revues, gestion de versions digne de ce nom. La performance et l'ergonomie fine, largement contraintes par la plateforme. La dépendance au fournisseur : une application low-code ne se migre pas, elle se réécrit, ce qui donne au choix de plateforme un caractère engageant, tarifs compris. Enfin l'intégration : au-delà des connecteurs standards, les échanges complexes ramènent du code — au pire endroit, dispersé dans des scripts intégrés à la plateforme. Pour un produit différenciant, exposé aux clients ou au cœur des opérations, le développement sur-mesure reste sans équivalent.

Le risque principal n'est pas dans l'outil, mais dans la prolifération : des dizaines d'applications créées au fil des besoins, sans inventaire, sans responsable identifié, sans gestion des accès ni des données, découvertes le jour où leur créateur quitte l'entreprise ou lorsqu'un audit s'y intéresse. C'est le schéma classique du shadow IT, reproduit à plus grande échelle parce que la barrière technique a disparu. La réponse n'est pas l'interdiction — elle ne ferait que déplacer le phénomène vers des outils grand public moins maîtrisables — mais l'encadrement : mieux vaut un usage visible et gouverné qu'une prohibition contournée.

Un cadre efficace tient en quelques règles claires. Un inventaire obligatoire : toute application créée est déclarée, avec un responsable nommé. Une grille de classification qui détermine le niveau d'exigence selon la sensibilité des données et la criticité de l'usage — l'outil personnel, l'application d'équipe et l'application traitant des données clients ne relèvent pas du même régime. Une formation minimale des citizen developers, couvrant notamment la protection des données. Une revue périodique du parc, pour archiver ce qui ne sert plus et repérer ce qui a grossi au point de mériter mieux. Et un chemin d'escalade assumé : quand une application dépasse le cadre, elle est reprise en développement classique — signe de succès, non d'échec. Ainsi gouverné, le low-code trouve sa juste place : un accélérateur pour la longue traîne des besoins internes, en complément du sur-mesure là où l'entreprise joue sa différence.