Entretenir des applis créées avec l'IA : ce que personne ne vous dit sur la deuxième semaine

Le premier week-end avec Proyecta, vous livrez quelque chose de réel. Ça marche. Vos utilisateurs (ou votre équipe, ou votre vous futur) commencent à s’en servir. Et puis c’est lundi et un client vous écrit : « Tu peux ajouter un menu déroulant pour filtrer par région ? »

Bienvenue dans la maintenance. C’est la partie de la création d’une appli avec l’IA dont personne ne parle, et la partie où la plupart des projets deviennent un actif durable ou s’effondrent discrètement. La bonne nouvelle, c’est qu’entretenir une appli créée avec l’IA est une expérience différente d’entretenir du code traditionnel. La nouvelle honnête, c’est que « différent » ne veut pas dire « gratuit ».

Ce que veut vraiment dire la maintenance

Quand les développeurs professionnels disent « maintenance », ils entendent à peu près quatre choses :

Ajouter de petites fonctionnalités que les gens réclament après le lancement.
Corriger des choses qui ont cassé ou qui étaient fausses dès le départ.
Suivre les changements extérieurs à votre appli — un fournisseur de paiement met à jour son API, un nouveau navigateur sort, la forme de vos données change.
Faire le ménage pour que le code ne se transforme pas lentement en marécage.

Pour une appli créée avec l’IA, ces quatre choses arrivent toujours. Ce qui change, c’est qui les fait et la façon dont le travail se ressent.

La bonne nouvelle : vous pouvez lui parler

Voici la partie que personne ne vous a dite à l’époque où vous copiiez-colliez du code de vieux tutoriels. Avec un créateur d’applis avec IA, vous entretenez l’appli de la même façon que vous l’avez créée : en décrivant ce que vous voulez.

Un vrai exemple. Une fondatrice que nous connaissons a construit un petit CRM pour son activité de coaching — clients, séances, suivi des paiements, tout le tralala. Trois semaines après le lancement, une cliente a mentionné qu’elle adorerait voir combien de séances elle avait faites cette année-là. Elle a ouvert l’appli et dit : « Ajoute un compteur “séances cette année” à chaque fiche client, en tirant de la table des séances où la date est en 2026. » Douze minutes plus tard, c’était en ligne. Elle était de retour au coaching.

Cette histoire paraît banale jusqu’à ce qu’on se rappelle l’alternative : relancer un freelance, attendre deux jours, payer 300 $, relire une pull request qu’elle ne comprenait pas tout à fait, et prier pour que rien d’autre ne casse. La boucle de maintenance n’est pas plus rapide parce que l’IA est plus maligne que le freelance. Elle est plus rapide parce qu’il y a moins d’humains dans la boucle.

La nouvelle plus difficile : les petites choses s’accumulent

Voici la partie qui surprend les gens. Les applis créées avec l’IA semblent faciles à modifier parce qu’ajouter des choses est facile. Ce qui n’est pas facile, c’est de garder l’ensemble cohérent à mesure qu’il grandit.

Quelques schémas qui dérapent, selon nos observations :

L’enchevêtrement accidentel. Vous demandez « ajoute un champ de remise au paiement ». Six révisions plus tard, la logique de remise vit à trois endroits, et un seul est correct. Rien n’a encore cassé, mais le prochain changement va être déroutant.
L’exigence oubliée. Vous avez ajouté « livraison gratuite au-delà de 50 $ » en mars. En mai, vous demandez à l’IA de « refaire le paiement pour gérer les cartes cadeaux ». Elle le fait. La règle de livraison gratuite a disparu. Personne ne l’a remarqué pendant deux semaines.
La dérive. Votre appli a commencé comme « un outil pour moi ». Elle est désormais utilisée par votre équipe. Le modèle mental de l’IA reste « pour moi », parce que c’est ce que vous avez dit au départ. Les nouvelles fonctionnalités sonnent étrangement faux, sans que vous arriviez à mettre le doigt dessus.

Aucun de ces cas n’est un échec des créateurs d’applis avec IA. Ce sont des échecs de mémoire et de contexte partagé — les mêmes problèmes qu’une équipe de développeurs humains, juste sous une autre forme.

Comment vous organiser

Les équipes qui s’en sortent bien avec la maintenance partagent quelques habitudes. Ce ne sont pas des habitudes techniques, pour la plupart. Ce sont des habitudes sur la façon de décrire ce qu’est votre appli et ce qui a changé.

Tenez un document « ce qu’est cette appli ». Une page. Le public, les objectifs, les règles (« livraison gratuite au-delà de 50 $ », « on n’envoie jamais d’e-mail aux utilisateurs le dimanche », « le téléphone est la clé primaire, pas l’e-mail »). Quand vous demandez à l’IA de changer quelque chose, collez la règle concernée dans le prompt. Vous ne court-circuitez pas l’intelligence de l’IA ; vous lui fournissez le contexte qu’elle ne peut pas mémoriser.

Décrivez les changements en termes de comportement, pas de code. « Je veux que les utilisateurs retrouvent leur filtre de région d’une session à l’autre » est une bien meilleure demande que « ajoute du localStorage au filtre ». La première décrit ce que vous voulez ; la seconde prescrit l’une des quinze façons de le faire, et probablement pas la meilleure.

Faites les changements un à la fois. Deux changements dans un même prompt, c’est l’un des deux qui peut échouer silencieusement sans que vous sachiez lequel. La façon la plus rapide d’entretenir une appli avec l’IA, c’est de garder vos itérations assez petites pour voir, d’un coup d’œil, si le résultat est correct.

Regardez ce qui a changé. La plupart des créateurs d’applis avec IA vous montrent un aperçu. Servez-vous-en. Les trente secondes passées à cliquer partout pour confirmer que la nouvelle fonctionnalité marche et que les anciennes marchent toujours sont l’assurance la moins chère que vous achèterez cette année.

Ce que vous ne pouvez pas faire (et que vous ne devriez sans doute pas)

Il y a une tentation, une fois qu’on a créé une appli avec l’IA, de penser qu’elle peut aussi l’exploiter à votre place. Elle ne le peut pas, et l’écart est réel :

Elle ne vous dira pas quand quelque chose a cassé silencieusement. Journaux, surveillance, astreintes — ce sont toujours un sujet à part. La plupart des créateurs d’applis avec IA ne surveillent pas votre appli en production comme le ferait un ingénieur back-end.
Elle ne connaît pas le monde extérieur à votre appli. Si un fournisseur de paiement abandonne une API, l’IA ne le sait pas tant que vous ne le lui dites pas. Abonnez-vous aux notes de version de vos fournisseurs. Lisez vos e-mails.
Elle ne peut pas prendre les décisions produit à votre place. Ajouter ou non une fonctionnalité, quel compromis faire, ce que vos utilisateurs veulent vraiment — c’est toujours vous. L’IA est une paire de mains très rapide ; le cerveau, c’est le vôtre.

Le tableau réaliste

Au bout de six mois avec une appli créée avec l’IA, la plupart des gens à qui nous parlons en arrivent à peu près là : ils consacrent peut-être deux à quatre heures par mois aux changements, presque tout en conversation. Les grosses refontes qu’ils redoutaient autrefois — « je veux ajouter toute une nouvelle section » — se font en un bon après-midi. Le côté ennuyeux — « le format de date est faux dans l’export » — se règle en un bon prompt.

Ce qu’ils n’ont pas, c’est le bruit de fond constant d’un code traditionnel : mises à jour de dépendances, migrations de frameworks, correctifs de sécurité, configurations de build. Ce bruit a été absorbé par la plateforme. Vous payez la plateforme pour s’en occuper, ce qui est une bien meilleure affaire que de payer un développeur pour le faire.

Si vous vous apprêtez à créer votre première appli, l’article sur ce que devrait être votre première appli créée avec l’IA vaut la peine d’être lu avant de vous lancer. Et si vous êtes déjà à quelques semaines et que vous ressentez certains des schémas ci-dessus, c’est normal. Écrivez votre document « ce qu’est cette appli » ce week-end. Votre vous futur, dans trois mois, en train de demander un nouveau tableau de bord, vous en sera très reconnaissant.