Créer une appli n’a jamais été aussi facile. Le vrai problème commence après « Publier »

Il y a encore quelques années, transformer une idée en application supposait généralement de savoir coder, de trouver un développeur ou de payer une agence. En 2026, cette première barrière s’est brutalement abaissée.

Des outils no-code et des générateurs pilotés par IA peuvent désormais produire une interface, une base de données et une partie de la logique applicative à partir d’une simple description. Bubble promet par exemple de générer une application fonctionnelle à partir d’un prompt, puis de permettre sa modification visuelle sans toucher au code.

La révolution est réelle. Mais elle crée un malentendu : rendre la fabrication accessible ne rend pas automatiquement le produit fiable, sécurisé, conforme ou durable.

Une phrase peut désormais produire un prototype

Bubble revendique aujourd’hui 6 millions de builders et 8 millions d’applications créées sur sa plateforme. Son générateur IA peut construire les pages, les types de données et les workflows d’une application à partir d’une description textuelle.

Le changement est considérable pour un entrepreneur, une association, un enseignant ou une petite entreprise. Une idée qui aurait nécessité plusieurs semaines de cadrage technique peut devenir un objet testable beaucoup plus rapidement.

Cela ne signifie pas qu’une application complexe est terminée en quelques minutes. Cela signifie que la première version visible, celle qui permet de montrer le concept à un utilisateur, n’est plus réservée à ceux qui maîtrisent un langage de programmation.

Le bouton « Publier » n’est pourtant pas un passe-droit

Les stores rappellent immédiatement la différence entre fabriquer et distribuer.

Apple indique que toutes les applications soumises à l’App Store sont examinées. Elles doivent être suffisamment complètes, stables, testées sur appareil et accompagnées de liens fonctionnels vers le support et la politique de confidentialité. Apple précise même que plus de 40 % des problèmes non résolus lors de la review sont liés à la règle d’exhaustivité : crashs, contenu incomplet, informations manquantes ou fonctionnalités non prêtes.

Google impose lui aussi une étape que le bouton d’un générateur ne peut pas supprimer. Pour les comptes développeur personnels créés après le 13 novembre 2023, l’accès à la production exige notamment un test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs, puis une demande d’accès à la production.

Autrement dit, une IA peut produire un prototype. Elle ne peut pas déclarer seule que ce prototype mérite d’être confié au public.

Une application peut fonctionner et quand même être mal conçue

Le risque le plus trompeur est là. Une application qui s’ouvre, affiche les bonnes pages et enregistre des données peut donner l’impression d’être terminée.

Pourtant, la CNIL demande aux éditeurs d’applications mobiles de minimiser les données collectées, de choisir les permissions réellement nécessaires et d’intégrer la sécurité et la protection des données dès la conception. Elle recommande également de surveiller les SDK et bibliothèques externes et de prévoir des mises à jour fréquentes, notamment lorsque des correctifs de sécurité deviennent nécessaires.

Ces obligations ne changent pas selon la méthode de fabrication. Une base de données construite visuellement reste une base de données. Un mauvais réglage d’accès reste un mauvais réglage d’accès. Une application générée par IA reste sous la responsabilité de ceux qui décident de l’exploiter.

Le no-code déplace la complexité plus qu’il ne la supprime

Le développement traditionnel expose directement la complexité : architecture, code, tests, déploiement. Le no-code masque une partie de cette mécanique derrière des composants, des workflows et des connecteurs.

C’est précisément ce qui rend ces outils puissants. Mais cela signifie aussi que le créateur doit comprendre ce que font les briques qu’il assemble : quelles données traversent quel service, qui peut accéder à quoi, comment les sauvegardes fonctionnent et ce qui se passe lorsqu’une API ou un connecteur change.

Dans les entreprises, Microsoft a dû formaliser cette question au niveau de Power Platform. Ses politiques de données permettent aux administrateurs d’empêcher certaines combinaisons de connecteurs et peuvent suspendre ou placer en quarantaine une application qui enfreint les règles définies.

Le message est révélateur : plus la création devient accessible aux métiers, plus la gouvernance devient nécessaire.

Le vrai test commence avec les premiers utilisateurs

Avant eux, une application vit dans un environnement prévisible. Après eux arrivent les mots de passe oubliés, les mauvaises saisies, les paiements refusés, les appareils anciens, les connexions lentes, les demandes de suppression de compte et les comportements que le créateur n’avait jamais imaginés.

C’est aussi à ce moment que le produit acquiert une responsabilité économique. Il faut répondre aux utilisateurs, corriger les bugs, surveiller les coûts, maintenir les intégrations, documenter les incidents et décider quelles fonctionnalités méritent encore d’être développées.

Une application n’est donc pas seulement un fichier ou une interface. C’est un service qui continue d’exister après sa mise en ligne.

Le nouveau goulot d’étranglement n’est plus forcément le code

La démocratisation du développement change profondément le profil du créateur. Un expert métier peut désormais tester lui-même une idée sans attendre qu’une équipe technique transforme son besoin en spécification.

C’est un progrès considérable. Mais le pouvoir de construire déplace aussi la responsabilité vers des personnes qui n’avaient auparavant pas à penser à l’authentification, au RGPD, aux paiements ou à la sécurité.

Le véritable avantage compétitif pourrait donc devenir moins la capacité à fabriquer une application que la capacité à décider ce qui mérite d’être construit, à tester sérieusement, à protéger les utilisateurs et à arrêter rapidement ce qui ne fonctionne pas.

Créer devient facile. Exploiter reste un métier.

L’IA et le no-code ont presque supprimé le coût psychologique du premier prototype : on peut commencer sans savoir exactement comment le logiciel sera construit.

Ils n’ont cependant supprimé ni les règles des stores, ni la protection des données, ni la maintenance, ni le support, ni la responsabilité de l’éditeur.

Le changement le plus important est donc peut-être ailleurs : pendant longtemps, la question était « qui sait programmer ? ». Désormais, de plus en plus de personnes peuvent construire. La question devient : qui saura transformer ce pouvoir en produit suffisamment utile, fiable et responsable pour durer après le bouton « Publier » ?