10 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Oui. Vous décrivez une application en quelques phrases, et un outil d’IA en produit une première version : des écrans, des formulaires, une base de données, une adresse où l’ouvrir. Pour tester une idée, cela change beaucoup.
La question utile vient juste après. Cette application peut-elle encaisser des paiements ? Garder les données de vos clients ? Servir vos utilisateurs tous les jours, pendant des années ? Là, la réponse dépend moins de l’outil que de ce qu’on fait autour.
Trois familles d’outils répondent à cette question.
Les créateurs d’applications par IA. Vous décrivez ce que vous voulez dans une conversation. L’outil génère l’application, l’héberge et la met en ligne, sans une ligne de code à écrire. Ce sont eux qui occupent la première page de Google sur cette recherche.
Les assistants conversationnels. Est-ce que ChatGPT peut créer une application ? Il en écrit le code, morceau par morceau, et l’explique. L’assembler, l’installer sur un serveur et la mettre en ligne reste à votre charge.
Les assistants de code, intégrés à l’outil de travail du développeur. Ils écrivent, modifient et testent du code à sa demande. Ils s’adressent aux développeurs, et les développeurs s’en servent : près de 90 % des professionnels de la tech interrogés par le rapport DORA 2025 utilisent l’IA dans leur travail. Ce rapport vient de DORA, le programme de recherche de Google Cloud sur le développement et la mise en production des logiciels.
Construire une application en décrivant ce qu’on veut, sans lire le code que l’IA écrit, porte un nom : le vibe coding. Le terme vient d’Andrej Karpathy, chercheur en intelligence artificielle, dans un message publié en février 2025. Il y décrit une façon de programmer où l’on accepte toutes les modifications proposées sans les lire, et où l’on colle les messages d’erreur dans la conversation jusqu’à ce que cela marche. Il précise lui-même que cela convient aux projets personnels jetables, menés le week-end.
Le développeur Simon Willison a posé la distinction qui compte ici. Le vibe coding, c’est construire avec l’IA sans relire le code qu’elle produit. Quand un développeur relit, teste, et sait expliquer chaque ligne à quelqu’un d’autre, il fait du développement logiciel. Assisté par l’IA, mais du développement logiciel.
Tester une idée. Montrer un écran à un associé, à un client, à un futur utilisateur, avant d’engager un budget. Construire un petit outil interne, utilisé par quelques personnes, qui ne touche ni à l’argent ni à des données personnelles.
Allen Holub le dit sans détour : le vibe coding a sa place pour les prototypes jetables. Le mot qui compte est « jetable ». Un prototype sert à apprendre quelque chose. Puis on le jette.
Une application qui fonctionne pendant une démonstration a prouvé une chose : elle fonctionne pendant une démonstration. Holub dresse la liste de ce qu’un « cela marche » ne garantit pas : la sécurité, le respect des règles sur les données, la montée en charge et la disponibilité du service quand beaucoup d’utilisateurs se connectent, la sauvegarde, la facilité à la faire évoluer. Pour une entreprise, cinq points pèsent plus que les autres.
L’éditeur Veracode a fait écrire du code à plus de 100 modèles d’IA, sur 80 tâches où l’on pouvait choisir une solution sûre ou non. Dans environ 45 % des cas, le code contenait une faille de sécurité. Les modèles plus récents ne font pas mieux que les anciens sur ce point.
Sur la vitrine d’un créateur d’applications par IA, un ingénieur a analysé 1 645 applications publiées. 170 d’entre elles, environ une sur dix, laissaient n’importe qui consulter les données de leurs utilisateurs : noms, adresses e-mail, informations financières.
Dès qu’une application conserve des noms, des adresses ou des informations sur vos clients ou vos salariés, le RGPD s’applique. L’entreprise qui collecte ces données doit les protéger par des mesures techniques adaptées au risque (article 32). En cas de fuite, elle doit la signaler à la CNIL, si possible dans les 72 heures (article 33). Les amendes peuvent atteindre 20 millions d’euros ou 4 % du chiffre d’affaires mondial, le montant le plus élevé étant retenu (article 83).
Cette obligation pèse sur l’entreprise qui collecte les données. Elle ne change pas selon l’outil qui a écrit le code.
Pour encaisser un paiement, une application passe par un prestataire de paiement. Le point délicat vient après : le prestataire prévient l’application qu’un paiement a été reçu, et l’application doit vérifier que ce message vient bien de lui. Sans cette vérification, n’importe qui peut envoyer un faux message et déclencher l’envoi d’une commande. Le prestataire peut aussi envoyer le même message deux fois, et l’application ne doit l’enregistrer qu’une fois. Les prestataires l’écrivent dans leur propre documentation, Stripe comme Adyen.
Dans une démonstration, personne ne fait de véritable paiement. Ces problèmes n’y apparaissent donc pas.
Une application vit en production. Elle doit suivre les mises à jour de sécurité, les changements de votre activité, les demandes de vos utilisateurs. La maintenance consiste à ajuster l’application en continu à l’évolution de ces besoins. Il faut comprendre ce qui doit changer, puis l’intégrer à l’application existante sans casser ce qui fonctionne.
Allen Holub fixe la condition pour qu’une IA fasse ce travail : intégrer les besoins des utilisateurs dans le système existant avec le moins de changements possible, sans dégrader l’ergonomie ni l’architecture, et sans bug. Pour lui, ce n’est pas encore le cas. Un humain reste nécessaire pour comprendre ce qu’il faut changer et adapter l’application aux personnes qui s’en servent.
Karpathy le note dans son message : le code grandit au-delà de ce qu’il en comprend. Pour un projet personnel mené le week-end, peu importe. Pour une application dont vos utilisateurs dépendent, chaque modification devient un pari quand plus personne ne sait ce que fait le code.
Et la maintenance coûte plus cher que le développement lui-même, comme nous l’expliquons dans l’article sur les projets logiciels qui dépassent leur budget.
Une démonstration se fait avec un seul utilisateur. Holub range la montée en charge parmi les propriétés qu’un « cela marche » ne garantit pas. Ce qui répond bien à une personne peut ralentir, ou tomber, quand de nombreux utilisateurs s’y connectent en même temps.
Le critère n’est pas la taille de l’application. C’est ce qui se passe si elle tombe en panne, si elle produit des résultats faux, ou si ses données fuient.
Faites appel à un professionnel quand votre application :
Tant que rien de cela n’est en jeu, l’outil seul suffit souvent.
Faire appel à un professionnel ne veut pas dire renoncer à l’IA. Les équipes de développement l’utilisent, elles aussi. La différence se trouve autour du code : des tests automatisés qui vérifient chaque modification avant qu’elle n’atteigne vos utilisateurs, une relecture de ce que l’outil a écrit, des mises en production qui ne cassent pas ce qui marchait la veille.
Le rapport DORA 2025 décrit l’IA comme un amplificateur. Elle renforce les équipes qui ont déjà de bonnes pratiques, et aggrave les difficultés des autres. Le rapport s’appuie sur les réponses de près de 5 000 professionnels de la tech. Il mesure deux choses : combien de modifications une équipe met en production, et combien d’entre elles posent problème une fois en ligne. Plus une équipe utilise l’IA, plus elle déploie de modifications. Mais, comme l’année précédente, ces modifications tournent aussi plus souvent mal. Par exemple, une modification casse quelque chose, et il faut soit revenir en arrière, soit corriger en urgence. Autre cas : un incident touche les utilisateurs, et l’équipe doit publier une réparation qui n’était pas prévue.
Allen Holub l’écrit dans « No Agentic SDLC, only Agentic coding » : l’IA fait du coding, qui n’est qu’une petite partie du développement logiciel. Selon lui, tant qu’une IA ne saura pas mener une conversation avec les utilisateurs pour faire émerger leurs besoins, ce travail reste humain.
Avec l’IA, écrire du code coûte peu, et la vérification devient le goulot d’étranglement, dit Dave Farley dans son entretien pour le podcast d’Aviator (« Engineering Discipline in the AI Era », février 2026).
Alexandre Poitevin dit pratiquer Python depuis dix ans. Il raconte, dans une publication LinkedIn, qu’il avait proposé son aide à Bryan Finster, qui travaillait sur une base de code Python sans en avoir l’habitude. Bryan Finster est développeur depuis 1996. Entré chez Walmart en 2001, il y a écrit des logiciels pour la chaîne logistique, puis aidé l’entreprise à étendre la livraison continue à ses équipes. Il maintient aujourd’hui MinimumCD.org, un site qui décrit les pratiques minimales de la livraison continue. Au final, Bryan Finster n’a pas eu besoin de l’aide d’Alexandre. Il savait piloter un agent IA. Pour Alexandre Poitevin, ce qui comptait, c’étaient les principes que Bryan Finster maîtrisait (stratégie de test, gestion des dépendances), plus que la connaissance du langage.
Ce n’est pas l’IA qui lui a permis de travailler sans connaître Python. C’est sa maîtrise des bases de l’ingénierie logicielle. Ces bases valent quel que soit le langage. Dans un commentaire, Bryan Finster ajoute que le jour où il a décidé de faire passer une partie d’un système de .NET Framework à .NET Core, il n’avait jamais vu de code .NET.
Chez DEVEDANOS, c’est ainsi que nous travaillons. L’IA fait partie de nos outils, à l’intérieur d’une approche où chaque modification est vérifiée par des tests automatisés. Pour le développement d’un logiciel sur mesure, nous travaillons pour un budget fixe, facturé chaque fin de mois pour le travail réalisé. Votre application est utilisable en un mois, en quelques fonctionnalités essentielles : vos utilisateurs s’en servent immédiatement, et c’est leur usage qui définit les fonctionnalités suivantes à développer. Une fois recettée et mise en ligne, chaque fonctionnalité est jugée sur la réaction de vos utilisateurs, et nous décidons aussitôt avec vous des suivantes, tant que vous le souhaitez. Une application vivante n’est jamais finie : si l’on cesse de la faire évoluer, elle ne reçoit plus que des correctifs de sécurité et des mises à jour des composants sur lesquels elle repose, et c’est une application qui se meurt.
Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Notre guide reprend ces sources en détail. Vous y trouverez aussi les questions à poser avant de signer un devis pour le développement de votre outil sur mesure.
Vous avez une application créée avec l’IA qui doit tenir en production, ou un outil qui ne suit plus votre activité ? On en parle ?
Livraison continue (continuous delivery) et déploiement continu (continuous deployment) ne diffèrent que d'un geste. Pourquoi un petit changement fréquent est moins risqué qu'un gros, sources à l'appui.
Feature flag, c'est quoi ? Quatre types de toggles, ce qu'il faut essayer avant d'en ajouter un, et sept anti-patterns qui font tourner du code jamais testé.
Quel budget pour créer une application ? Le montant ne suffit pas : visez un objectif plutôt qu'une liste, avec des utilisateurs dès le premier mois.