Le low-code et le vibe coding rendent le développement de logiciels plus accessible que jamais. Cependant, toutes les applications ne se prêtent pas à chaque approche. Quand est-il préférable d’utiliser telle ou telle technologie ?
Le low-code et le vibe coding offrent de plus en plus de possibilités aux développeurs et peuvent accélérer les processus d’entreprise. Pourtant, des pièges subsistent : du verrouillage des licences pour les applications critiques à la perte de contrôle sur ce que l’IA construit précisément.
« Le choix du low-code ou du vibe coding dépend fortement du contexte et de l’application », explique Dirk Deridder, CTO chez Smals, lors d’une table ronde organisée par ITdaily. Comment exploiter le potentiel de ces technologies en évolution rapide sans s’enliser ?
Autour de la table se trouvent également Bjorn Boisschot, Quality Engineering Manager chez Cegeka, Stijn Lambrechts, Global Delivery Lead Applications chez Cegeka, Pieter Vercammen, Solutions Architect chez Mendix et Ron Pooters, directeur du Microsoft Innovation Hub à Bruxelles.
Lettres vertes
« Le low-code existe depuis plus de 20 ans », commence Vercammen. Pourtant, de nombreuses organisations se heurtent à un problème d’adoption. Vercammen souhaite ici briser un stéréotype : « Beaucoup d’entreprises pensent que les vrais logiciels ne sont créés que par des développeurs chevronnés, c’est-à-dire des personnes assises dans une pièce à fixer des lettres vertes », raconte-t-il en riant.
Le low-code reste une question d’évangélisation.
Pieter Vercammen, Solutions Architect chez Mendix
Il remarque que la plupart des clients qui franchissent le seuil d’adoption du low-code s’en sortent avec succès. « Mais cela reste une question d’évangélisation. »
Applications critiques
Tout le monde ne choisit pas cette voie, et ce pour plusieurs raisons. « Nous n’utilisons pas le low-code et c’est un choix délibéré », déclare Deridder. Bien qu’ils aient examiné avec beaucoup d’enthousiasme les possibilités du low-code, ils ont pris une autre direction avec Smals. Selon Deridder, cela est lié au type d’application.
Le contexte détermine la technologie que vous choisissez.
Dirk Deridder, CTO chez Smals
Smals construit principalement de grandes plateformes de back-office avec de nombreuses transactions, et ces cas d’utilisation ne se prêtent pas bien au low-code selon eux. « À cela s’ajoute le fait que le gouvernement travaille sur un horizon temporel très différent de celui d’une entreprise classique : les applications doivent durer 30 ans ou plus. Sur le plan commercial, beaucoup de choses peuvent changer en deux décennies, et cela pèse dans chaque choix technologique », explique Deridder.
Vercammen, en revanche, voit un potentiel dans le low-code pour les grandes applications. « Nous voyons des applications critiques pour l’entreprise réalisées en low-code. Chaque colis livré à votre porte par PostNL est entièrement construit sur un backend basé sur le low-code. C’est un mythe qu’il faut briser », estime-t-il.
Verrouillage des licences
Lambrechts rejoint l’analyse de Deridder. Il souligne que le verrouillage (lock-in) avec le low-code ne se situe pas au niveau du partenaire de mise en œuvre, mais purement au niveau des licences. C’est précisément ce que craignent les clients. « Si vous avez construit une application complexe et critique pour l’entreprise qui doit durer jusqu’à 20 ans, vous ne pouvez pas partir sans un investissement lourd si les règles de licence sont modifiées », explique Lambrechts.
Le verrouillage avec le low-code ne se situe pas au niveau du partenaire d’implémentation, mais au niveau des licences.
Stijn Lambrechts, Global Delivery Lead Applications chez Cegeka
Il affirme que le développement spécifique offre plus de contrôle : « le coût de la licence est quasi inexistant et vous pouvez gérer l’infrastructure de manière plus flexible. Le revers de la médaille a toujours été qu’il fallait plus d’heures de travail, mais cet argument perd du terrain maintenant que l’IA accélère le développement. » Lambrechts s’attend donc à ce que le développement spécifique redevienne plus attractif.
L’IA comme catalyseur ?
Selon Vercammen, l’IA apporte toutefois de plus en plus de solutions. « Ce que nous voyons actuellement avec l’IA, c’est qu’elle accélère énormément le replatforming de la plateforme A vers la plateforme B. » La possibilité de migrer devient ainsi moins une garantie théorique et plus une réalité pratique.
Pourtant, il nuance immédiatement : la viabilité à long terme des fournisseurs d’IA eux-mêmes n’est pas une évidence. « De nombreuses entreprises de logiciels brûlent des milliards. OpenAI perd chaque mois plus que le déficit budgétaire annuel de la Belgique. À un moment donné, on se pose la question : est-ce une solution viable à long terme ? »
La facilité de migration offerte par l’IA résout donc en partie la question du verrouillage, mais crée en même temps une nouvelle dépendance : celle envers des fournisseurs dont le modèle économique est loin d’être prouvé.
Runtime
L’indépendance vis-à-vis de l’environnement d’exécution (runtime) est une exigence stricte pour Deridder. « Nous voulons pouvoir faire fonctionner les applications même après d’éventuels problèmes avec le fournisseur. Les plateformes qui s’inscrivent dans un écosystème ouvert, comme Java, offrent plus d’autonomie et de flexibilité pour porter l’application vers un autre runtime plus tard », affirme-t-il.
La même logique s’applique selon lui à l’IA. « Tant que l’IA n’est utilisée que pour générer du code ou des programmes statiques, le coût des tokens au runtime ne joue aucun rôle. Dès qu’une application a besoin d’un système d’IA au runtime pour prendre des décisions, le contexte devient déterminant. »
« IA-ifier »
Boisschot apporte une nuance supplémentaire. Utiliser l’IA pour quelque chose de déterministe est, selon lui, inutile. « Si un plus un font deux, pourquoi le demander à un LLM ? Le danger est que les entreprises veuillent tout “IA-ifier”, alors que la moitié est inutile ou coûte simplement beaucoup d’argent. »
De plus, il met en garde contre la différence entre human in the loop et human in control. L’un signifie qu’un humain est impliqué quelque part dans le processus, l’autre que l’humain conserve la décision finale et surveille la qualité. Quiconque ignore cette distinction prend des risques. »
Deridder reconnaît également cette différence. Le regard critique humain reste indispensable. « Surtout pour les systèmes critiques, comme les soins de santé ou la sécurité sociale, l’humain doit finalement prendre la décision finale. La précision et l’explicabilité y sont trop importantes. »
Ne pas lutter contre la technologie
Le low-code et le vibe coding ne sont donc pas intéressants au même degré partout. Deridder insiste sur le fait que le contexte reste primordial. Cela ne signifie toutefois pas qu’il ne faut pas les utiliser. Vercammen a déjà évoqué des applications réussies avec le low-code, et le vibe coding offre également une valeur ajoutée pour accélérer les processus, « tant qu’il ne se trouve pas dans le runtime », selon Deridder.
« La dernière chose à faire est de lutter contre la technologie », affirme Pooters. Les outils évoluent plus vite que les organisations ne peuvent suivre, mais cela ne doit pas être une excuse pour l’immobilisme.
La dernière chose à faire est de lutter contre la technologie.
Ron Pooters, directeur van de Microsoft Innovation Hub in Brussel
Le défi n’est pas de choisir entre le low-code, le vibe coding ou le développement sur mesure, mais de comprendre quand chaque approche est appropriée et de construire une stratégie réfléchie à ce sujet. Car comme le résume Deridder : « Celui qui a commencé hier a bel et bien une longueur d’avance. »