Écrire un logiciel a toujours été la partie bon marché. L'IA a rendu celle-là moins chère et a laissé la partie coûteuse intacte. Ce qui arrive à une application générée pendant sa première année d'exploitation, et comment calculer à l'avance qui la porte.
Il y a une phrase que presque tout dirigeant de petite entreprise entend aujourd'hui : « L'IA te fait ça en un après-midi. » Et c'est vrai. Cette phrase reste simplement muette sur ce qui vient après.
Écrire un logiciel n'a jamais été la partie coûteuse. La partie coûteuse, c'est la maintenance - toutes ces années où les lois, les processus et les gens changent et où plus personne ne se souvient pourquoi le code est écrit ainsi. L'IA a rendu le jour un moins cher. Elle a laissé les mille jours suivants exactement où ils étaient.
Une année dans la vie d'une application générée
Imaginez un suivi de chantiers que l'IA vous génère au printemps. Ça marche. Les collègues l'utilisent. Puis le temps passe.
Jour 1. En production. Tout le monde ravi : deux jours au lieu de deux mois.
Mois 2. Le taux de TVA change sur une ligne. Dans l'application, il est écrit en dur dans le code. Quelqu'un doit le trouver et le modifier. Ce quelqu'un, c'est vous, votre neveu, ou une personne que vous payez pour ça.
Mois 6. Une nouvelle collègue arrive à l'administration. Elle doit voir seulement ses chantiers. Rien de tel n'existe dans l'application, car le prompt d'origine ne parlait pas de rôles. Ajouter des droits n'est pas « un prompt de plus » - c'est une intervention qui doit tenir sur tous les écrans.
Mois 12. Quelque chose cesse de fonctionner. Celui qui a généré l'application n'est plus là ou ne se souvient plus. Il sait lire le code, mais il ne le comprend pas - une machine l'a écrit et personne ne l'a vraiment relu.
Écrire l'application est la partie bon marché
Au jour un, les deux voies se ressemblent. La différence apparaît au mois deux, six et douze - et à partir de là, elle ne fait que croître.
Pourquoi cela arrive presque toujours
Ce n'est pas que l'IA écrive du mauvais code. Le code est souvent étonnamment correct. Le problème est ailleurs et comporte trois couches.
Personne ne connaît ce code. Dans une application écrite classiquement, il existe au moins une personne qui sait pourquoi telle chose est faite ainsi. Dans une application générée, cette personne n'existe pas - il n'y a qu'un prompt et un résultat.
La maintenance ne se voit pas à l'avance. Quand une agence construit votre application, les coûts de maintenance figurent dans le devis. Quand vous la générez vous-même, ils ne figurent nulle part - ce qui ne veut pas dire qu'ils n'existent pas.
Les changements n'arrivent pas un par un. Une entreprise bouge en continu : nouveau type de chantier, nouveau taux, nouveau collègue, nouvelle exigence client. Chacun de ces changements est petit. Vingt petits changements par an font un mois de travail.
Trois questions avant de commencer
Avant de bâtir quelque chose d'important sur du code généré, trois questions concrètes valent la peine :
- Qui, dans l'entreprise, lira ce code quand ça cassera ? Si la réponse est « personne », vous n'avez pas une application, vous avez un engagement.
- Combien de changements attendons-nous par an et qui les fera ? Écrivez-les. La plupart des entreprises arrivent à huit ou vingt petites choses par an, et c'est un travail récurrent.
- Que se passe-t-il si cette personne part ? Avec du code à vous, c'est un risque que vous portez. Avec une plateforme, c'est un risque que porte le fournisseur.
Il ne s'agit pas de ne pas utiliser l'IA
L'IA est aujourd'hui une façon raisonnable de concevoir une application, de la décrire et de la faire construire. La différence tient à ce qui sort au bout : du code source dont vous devez vous occuper, ou une application tournant sur une plateforme qui prend en charge maintenance, sauvegardes et mises à jour.
Ce que « la plateforme s'en charge » signifie concrètement
Ceci : mises à jour, sauvegardes, correctifs de sécurité et compatibilité ne sont pas votre affaire. Quand une règle change, vous modifiez un champ ou une automatisation - et une personne non technique de l'équipe en est capable. Quand celui qui a construit le système s'en va, il reste une configuration lisible, pas du code que personne ne comprend.
Cela ne veut pas dire qu'une plateforme couvre absolument tout. Pour une logique vraiment singulière, il existe des sorties de secours via webhooks et API. La différence est de proportion : au lieu de l'application entière, vous ne possédez que l'exception.
À quoi ressemble une automatisation dans laquelle on peut regarder, c'est dans L'automatisation sans boîte noire. Et si vous pesez des générateurs précis, voyez Lovable, Bolt, v0 et consorts. Un panorama de tout le sujet dans le guide complet du no-code et du développement par IA.
Questions fréquentes sur la maintenance d'applications générées
L'IA ne peut-elle pas aussi réparer l'application ?
En partie, mais vous butez sur deux choses. L'IA doit savoir précisément ce qui ne va pas - et quelqu'un doit le repérer. Et la deuxième réparation se fait sur du code issu de la première, si bien qu'à chaque tour le risque de casser autre chose augmente.
Que coûte réellement la maintenance ?
Cela dépend de la fréquence à laquelle votre processus change. Un ordre de grandeur tiré d'applications d'entreprise ordinaires : comptez dix à vingt petits changements par an. Confiés à un externe, c'est une ligne récurrente du budget, pas une dépense unique.
Comment garder la main si je fais construire une application ?
Posez trois questions d'emblée : qui fera les changements, ce que coûte une heure de cette personne, et où seront stockées les données. Si un prestataire n'a pas de réponse à la dernière, personne ne s'occupe de la maintenance.