APPLICATIONS & RESPONSABILITÉ
Quand j’ai découvert Bubble, j’ai voulu dépasser la démonstration. Mon objectif était concret : construire une petite application de questionnaires pour animer des échanges et tester une idée.
En une quinzaine d’heures, j’avais une première version fonctionnelle sans écrire de code. Je m’étais franchement bien amusé. Pour quelqu’un qui avait connu des développements beaucoup plus longs, la promesse était difficile à ignorer.
Mais j’avais déjà une réserve : que se passerait-il si cette application devenait importante, puis complexe, puis impossible à reprendre par quelqu’un d’autre ?
Avec le no-code, le low-code et l’IA, cette question devient centrale. Produire une première version rapidement est une capacité. Faire tenir le service dans la durée en est une autre.
No-code, low-code et développement avec l’IA : des approches à distinguer
Le no-code permet de construire principalement par configuration visuelle. Le low-code combine cette approche avec des extensions ou du code lorsque c’est nécessaire. Le développement assisté par l’IA peut, lui, produire du code pour une application classique ou aider à configurer une plateforme.
Ces frontières ne sont pas toujours nettes. Mais il est utile de les distinguer : le modèle de maintenance, les compétences nécessaires et la dépendance à la plateforme peuvent différer.
Pour le dirigeant, la question n’est donc pas seulement de savoir si l’on a écrit des lignes de code. C’est de comprendre qui saura modifier l’application, où vivent ses données et ce qui permet de la remettre en marche.
Ce que mon premier essai de Bubble m’avait appris
La prise en main rendait les premiers résultats accessibles. Pourtant, j’avais besoin de réfléchir au schéma de données, au parcours des utilisateurs et aux échanges entre les écrans.
Ne pas écrire de code ne supprimait pas la conception. Cela déplaçait une partie du travail vers la configuration, les règles et l’organisation des données.
Mes réserves d’alors sur le versionnement ou les capacités d’un produit ne doivent pas être lues comme une évaluation actuelle de Bubble. Les plateformes évoluent. En revanche, le besoin de comprendre les dépendances et de préparer la reprise de l’application reste valable.
Les situations dans lesquelles je trouve ces approches utiles
Tester un besoin avec quelques utilisateurs. Remplacer une ressaisie limitée. Donner à une équipe un petit outil interne. Préparer un prototype pour clarifier ce que l’on attend avant d’investir davantage.
Ce sont de bons terrains lorsqu’on peut expliquer le périmètre, limiter les conséquences d’une erreur et observer l’usage. La rapidité permet d’apprendre à partir de quelque chose qui fonctionne, au lieu de discuter uniquement d’un cahier des charges.
Elle ne dispense pas de vérifier si un outil existant répond déjà au besoin. Avant de fabriquer une application, je regarderais aussi ce que l’on peut configurer, simplifier ou supprimer. C’est le sujet de mon guide acheter ou développer à l’ère de l’IA.
Le vrai point de bascule : quelqu’un commence à en dépendre
Un prototype devient parfois un outil quotidien sans décision explicite. On lui ajoute un utilisateur, puis une interface, puis une règle particulière. Il finit par porter une activité que plus personne ne veut interrompre.
C’est à ce moment qu’il faut revoir son cadre. Qui est responsable métier ? Qui intervient quand un flux échoue ? Les données peuvent-elles être récupérées ? Les accès suivent-ils les départs de collaborateurs ?
Le créateur ne doit pas devenir le seul point de passage. Une application très simple peut rendre un service important ; elle mérite alors une documentation et une organisation proportionnées à cette importance.
L’IA accélère la fabrication, mais le résultat reste à vérifier
Une première interface convaincante peut masquer des cas non traités. Une commande annulée, un doublon, une indisponibilité du service connecté ou un utilisateur sans le bon droit peuvent changer le résultat attendu.
Je distinguerais donc une démonstration, un essai sur un périmètre limité et un usage réel partagé. Les contrôles ne sont pas les mêmes à chaque étape.
L’IA peut aider à construire, expliquer ou corriger. Il faut néanmoins une personne capable de comprendre le fonctionnement et de vérifier les règles importantes. Plus le processus est critique, plus cette capacité de contrôle compte.
Une gouvernance légère, mais réelle
Il n’est pas nécessaire de transformer chaque petit outil en programme informatique. En revanche, quelques éléments doivent être faciles à retrouver :
- son usage et son responsable métier ;
- les données utilisées et les personnes autorisées à y accéder ;
- ses dépendances, ses coûts et la personne qui assure son support ;
- la manière de tester une modification et de récupérer les données ;
- les conditions pour le reprendre, le remplacer ou l’arrêter.
Microsoft consacre d’ailleurs une documentation à la gouvernance de Power Platform, notamment à l’administration et à la gestion des environnements. La configuration simple d’un outil ne supprime donc pas le besoin d’organiser son usage.
À l’échelle de l’entreprise, ce cadre doit rejoindre la gouvernance du SI. L’objectif est de donner aux métiers une liberté utile, avec une visibilité suffisante sur les applications dont ils dépendent.
La place de la DSI : rendre cette liberté durable
La DSI peut aider à choisir les plateformes, sécuriser les connexions et préparer les règles de passage vers un usage plus large. Elle peut aussi fournir des composants partagés pour éviter que chacun reconstruise le même accès à une donnée.
Elle n’a pas besoin de tout fabriquer elle-même. Mais si les applications se multiplient, quelqu’un doit garder une vue de l’ensemble. C’est aussi la question du best of breed : chaque outil peut être pertinent localement et compliquer le système collectif.
Je reste convaincu de la valeur de ces approches. Leur réussite se mesure à un service utilisé, maîtrisé et reprenable, pas seulement au temps nécessaire pour produire sa première version.
Si vos applications internes se sont accumulées ou si vous voulez passer d’un prototype à un usage fiable, un diagnostic SI peut aider à choisir ce qui doit être consolidé. Parlons de votre situation.
Article initial conservé à la même adresse et refondu le 14 octobre 2026.
