J’ai fait une app avec l’IA et elle ne tient pas : voici ce qui manque

Ce qui s’est passé, et pourquoi c’est normal

Vous avez décrit ce que vous vouliez, l’outil a produit quelque chose qui marchait, et vous avez eu raison d’y croire : ce que vous avez obtenu en quelques soirées aurait demandé plusieurs semaines il y a trois ans.

Puis vous avez voulu que d’autres l’utilisent, et les limites sont vite apparues. Ce n’est pas un échec, et ce n’est pas votre faute. C’est simplement que la partie visible d’une application représente une fraction du travail, et que c’est la seule partie qu’une conversation permet de décrire facilement.

Les quatre manques, toujours les mêmes

Les données ne survivent pas. Beaucoup de prototypes gardent l’information dans le navigateur ou dans un fichier qui se réinitialise. Tant que vous êtes seul à essayer, ça ne se voit pas. Dès qu’un collègue s’en sert depuis son poste, les données divergent, et le jour où quelque chose disparaît, il n’y a aucune sauvegarde parce qu’il n’y a rien à sauvegarder.

Il n’y a pas vraiment de comptes. Un écran de connexion n’est pas une authentification. La question n’est pas « comment on entre », c’est « qui a le droit de voir quoi, et qu’est-ce qui l’en empêche techniquement ». Dans la plupart des prototypes, la réponse est : rien. Toutes les données sont accessibles à qui sait demander.

Rien n’est prévu pour les cas anormaux. Le formulaire marche si on le remplit correctement. Personne ne remplit correctement. Champ vide, double clic, connexion coupée au mauvais moment, fichier de 40 Mo : chacun de ces cas produit soit une erreur incompréhensible, soit pire, une donnée à moitié écrite.

Ça tourne sur votre machine. Ce qui veut dire : ce n’est pas encore une application prête pour l’exploitation. Il manque un hébergement fiable, un nom de domaine, un certificat, des sauvegardes automatiques, et un moyen de mettre à jour sans impacter l’activité.

Ce qu’on garde, et ce qu’on restructure

Presque tout se garde, et c’est la bonne nouvelle. Ce que vous avez produit contient l’information la plus difficile à obtenir dans un projet : ce que vous vouliez vraiment. Les écrans, les enchaînements, le vocabulaire de votre métier, les cas particuliers auxquels vous avez pensé, tout cela a une valeur réelle, et un cahier des charges rédigé à froid ne l’aurait jamais capturé aussi bien.

Ce qui se refait, en général : la façon dont les données sont rangées, la couche des comptes et des droits, et la mise en production. Ce n’est pas la partie que vous aimiez faire, et c’est celle qui prend le moins de temps quand on l’a déjà faite cinquante fois.

Dans quel ordre reprendre

1. 1Figer ce qui existe. Une copie du code et des données, avant toute modification. Cela paraît évident et c’est l’étape la plus souvent sautée.
2. 2Poser une vraie base de données, et y reverser ce qui existe. À partir de là, plus rien ne se perd.
3. 3Mettre les comptes et les droits, avant d’ouvrir à quiconque.
4. 4Mettre en ligne, avec sauvegardes automatiques et un moyen de revenir en arrière.
5. 5Ensuite seulement, reprendre les fonctions une par une.

L’ordre compte : chacune de ces étapes rend la suivante plus simple, et l’inverse est faux.

Combien de temps

Beaucoup moins que refaire. Un prototype fonctionnel qui vous a demandé plusieurs semaines représente en général quelques semaines de reprise pour arriver en production, et vous savez déjà ce que vous voulez, ce qui supprime la partie la plus incertaine d’un projet.

C’est aussi pour ça qu’il vaut mieux ne pas jeter. Le réflexe du professionnel qui découvre un prototype est de proposer de tout recommencer proprement. C’est confortable pour lui, coûteux pour vous, et ça vous fait perdre la seule chose que vous aviez d’unique.