Selon l’étude « No-Code & Low-Code 2024 » récemment publiée par Numeum, plus de 45 % des entreprises françaises envisagent de développer au moins une application métier en no code (ou en low code) dans l’année. Un chiffre qui a de quoi faire frémir certains développeurs, lassés d’entendre que « demain, plus personne n’aura besoin de coder ». Alors, faut-il s’attendre à un monde où la programmation manuelle serait reléguée aux oubliettes ?
La vérité est probablement plus nuancée.
Le No Code : un allié ou une menace pour les développeurs ?
La crainte la plus courante exprimée par les plus pessimistes : « Le no code va nous piquer nos jobs. » Reste à voir si c’est vraiment le cas.
- Pour certains, c’est une libération : plus besoin de coder les formulaires basiques, les flux simples… on laisse ça aux métiers qui peuvent bricoler leur appli fonctionnelle sans aligner une seule ligne de script.
- Pour d’autres, ça pose question : « Si tout le monde peut faire de l’app, à quoi sert l’expertise du développeur ? »
Eh bien Jamy, en réalité, le no code n’est pas tant un rival qu’un complément.
Il prend en charge les tâches répétitives et standardisées, libérant le développeur pour qu’il se concentre sur des briques complexes : intégrations poussées, algorithmes spécifiques, performance, architecture… Autrement dit, tout ce qu’une plateforme no code ne gère pas toujours à la perfection.
Là où ça pique un peu, c’est lorsque les entreprises veulent absolument tout basculer en no code, sans cadrage, et s’attendent à ce que les devs « réparent » en cas de pépin.
Or, plus une plateforme est fermée, plus il est difficile de plonger dans la base du code pour effectuer des ajustements.
D’où l’importance de clarifier les rôles.
Comment cette approche transforme les rôles dans les équipes IT
Donc, les développeurs ne disparaissent pas, mais leur mission évolue :
- Moins de micro-tâches : Terminé, le script de 300 lignes pour générer un PDF standard, le no code fait ça tout seul. Les devs gagnent du temps pour se consacrer à des tâches à plus haute valeur ajoutée (sécurité, performance, gros modules).
- Un rôle de facilitateur : Les équipes métiers, désormais capables de prototyper des applications en no code, ont parfois besoin d’un coup de main pour gérer des cas plus pointus. Le développeur devient le référent technique, voire le « coach ».
- De la vigilance sur l’architecture : Quand les applis no code poussent comme des champignons, il faut quand même une vue globale pour éviter la dispersion. Les devs peuvent se charger ici de définir les bonnes pratiques (API, modèles de données, etc.).
Cette nouvelle répartition peut d’ailleurs booster la collaboration. Les métiers se sentent plus libres, l’IT se concentre sur l’expertise, et on gagne en efficacité…
…à condition évidemment de poser un minimum de règles pour qu’on n’installe pas trois plateformes no code différentes qui se marchent sur les pieds.
Les tâches que le No Code automatise… et celles qui nécessitent toujours du code
Alors concrètement on parle de quelles tâches/applis ?
Tâches automatisées par le no code
- Conception d’interfaces simples : formulaires, tableaux de bord, pages web classiques.
- Configuration de workflows : enchaînement de traitements conditionnels, envoi d’emails…
- CRUD basique : création, lecture, mise à jour et suppression de données via des modules tout prêts.
Tâches nécessitant toujours du code
- Optimisations lourdes : faire tourner des calculs intensifs, gérer d’énormes volumes de données, prévoir une scalabilité extrême.
- Algorithmes complexes : IA, reconnaissance d’images, cryptographie, etc.
- Personnalisations front-end poussées : animations riches, UX sophistiquée avec transitions complexes, etc.
- Sécurité avancée : dès que ça touche au chiffrement, à l’authentification multi-facteurs ou à la détection d’intrusions, mieux vaut avoir un expert dev derrière.
En gros, le no code fait merveille pour du standard, du reproductible. Dès qu’on sort de ce cadre, on re-bascule dans l’écriture « manuelle ».
L’illusion d’un « tout no code » est donc assez limitée dès que les projets deviennent complexes, notamment sur les « gros » logiciels sur mesure.
Pourquoi les entreprises doivent repenser la collaboration entre IT et métiers
Les utilisateurs métiers ne sont plus de simples « clients internes » qui attendent que la DSI livre la solution toute cuite.
Avec le no code, ils sont désormais capables de prototyper eux-mêmes un outil, de le tester, de l’améliorer en direct. Cette bascule implique néanmoins :
- Un cadre pour éviter la multiplication anarchique des applis no code. On ne veut pas se retrouver avec 50 mini-outils isolés.
- Une gouvernance pour la sécurité des données et la cohérence technique. Oui, c’est sympa de créer son appli marketing pour collecter des prospects, encore faut-il respecter le RGPD et assurer le lien avec le CRM !
- Un esprit de collaboration : que les devs ne perçoivent pas le no code comme un ennemi, et que les métiers ne considèrent pas l’IT comme un frein. Il faut jouer la carte du win-win.
Dans certains cas, on met même en place des « centres d’excellence no code » ou des « champions » formés pour accompagner les équipes, valider les approches et garantir la qualité.
Vers un futur où tout le monde pourra créer des applications ?
Sans doute que dans un horizon de quelques années, des plateformes encore plus simples, plus riches en fonctionnalités comme celle de DAZZM (à découvrir ici), permettront à monsieur/madame Tout-le-Monde de concevoir des applis internes complexes.
Un peu comme on a vu surgir des éditeurs de site web en drag-and-drop, ou des solutions de business intelligence self-service.
Faut-il pour autant enterrer le métier de développeur ? Clairement, non.
Les besoins en code from scratch subsistent, ne serait-ce que pour la performance, l’architecture, l’IA… Et puis, toute organisation un peu sérieuse aura toujours besoin de compétences pointues pour garantir la fiabilité du SI.
Le vrai changement, c’est qu’on glisse vers un modèle plus inclusif, où tout le monde peut participer à l’IT, et où l’IT ne fait plus cavalier seul.
Plus d’autonomie pour les métiers, plus de soulagement pour les devs, et au final un cycle de développement plus rapide et plus en phase avec la réalité terrain.