Une application faite avec l'IA, que plus personne ne comprend
Elle tourne, et vous vous en servez tous les jours. Mais le jour où elle casse, qui sait comment elle marche ?
Comment on en arrive là
Un jour, quelqu'un a décrit à un assistant IA ce dont l'entreprise avait besoin : vous-même, un collègue ou un développeur indépendant. Peu après, l'application tournait. C'était rapide, ça marchait, et c'était sans doute la bonne décision.
Puis les besoins ont changé. Chaque modification a été demandée à l'IA, empilée sur la précédente. Aujourd'hui, l'application fait tourner une partie de votre activité, et personne ne peut expliquer comment elle est construite.
- Chaque correction casse autre chose, ailleurs.
- Personne ne sait vraiment où sont les données, ni comment les récupérer.
- La personne qui l'a construite est passée à autre chose, n'a plus le temps, ou n'ose plus y toucher.
- Personne ne sait quels comptes et abonnements la font tourner, ni à quel nom.
Ce qui manque souvent dans une application faite vite
Ce n'est la faute ni de l'IA, ni de la personne qui l'a utilisée. C'est ce qu'on saute quand on va vite, et qu'aucun outil ne fait à votre place.
-
Pas de tests
Rien ne vérifie qu'une modification ne casse pas ce qui marchait. On le découvre quand un client appelle.
-
Pas de documentation
Ni plan, ni explication. Pour comprendre, il faut relire tout le code, ou reposer la question à l'IA, qui repart de zéro.
-
Des secrets dans le code
Des mots de passe et des clés d'accès écrits en clair dans le code, et parfois publiés avec lui.
-
Des données en désordre
Les mêmes informations à plusieurs endroits, sous plusieurs noms. Deux écrans donnent deux chiffres différents.
-
Des dépendances oubliées
Des bibliothèques ajoutées en chemin, restées à la version du premier jour, avec leurs failles connues.
-
Aucun responsable
Quand elle tombe en panne un vendredi soir, qui répond ? Une IA ne décroche pas le téléphone.
Ce qu'elle vous coûte vraiment
Une application faite vite coûte peu à construire. Elle peut coûter cher à garder.
- Combien de temps a pris la dernière correction, et qu'a‑t‑elle cassé ailleurs ?
- Si l'application s'arrête lundi matin, qui appelez‑vous, et combien de temps attendez‑vous ?
- Si une clé d'accès a fuité avec le code, qui s'en apercevrait, et quand ?
- Si un client ou un repreneur vous demande où sont vos données et qui peut y accéder, que répondez‑vous ?
Pourquoi ne pas simplement redemander à l'IA ?
Le code est devenu une commodité. La valeur est dans l'architecture, le diagnostic et la responsabilité.
Une IA écrit du code très vite. Elle peut même vous écrire un beau rapport sur le vôtre. Mais elle ne vous dit pas quels points actionner en premier, ni ce que chacun vous coûte. Elle ne voit pas ce que vos équipes font à côté de l'outil. Et elle ne répond d'aucune décision.
L'IA multiplie les applications que plus personne ne comprend. Les reprendre demande ce qu'elle ne fournit pas : quelqu'un qui lit l'ensemble, décide de ce qui doit changer d'abord, et en prend la responsabilité.
Votre application n'est pas à jeter pour autant. Elle contient vos règles métier, éprouvées par l'usage. C'est une base de travail, pas une erreur.
Cette semaine, sécurisez
Six vérifications qui ne touchent pas au code. Utiles même si vous ne nous appelez jamais.
- Le code. Vérifiez qu'il est dans un dépôt (GitHub, GitLab ou autre) au nom de votre entreprise, et pas seulement sur l'ordinateur ou le compte personnel de quelqu'un.
- Les comptes. Listez ceux dont l'application dépend : hébergement, base de données, nom de domaine, services d'IA, paiement, e‑mails. Notez qui les détient et qui les paie.
- Les sauvegardes. Faites une sauvegarde de la base de données, et vérifiez qu'elle peut être restaurée.
- Les secrets. Cherchez les mots de passe et les clés écrits dans le code ou collés dans les conversations avec l'IA. S'il y en a, faites-les changer par quelqu'un qui sait où l'application les utilise, sinon c'est la panne.
- Les conversations. Gardez les échanges et les consignes qui ont servi à construire l'application : pour l'instant, c'est sa seule documentation.
- La mise en ligne. Notez qui sait aujourd'hui mettre une nouvelle version en ligne, et comment.
La liste complète, avec les accès et le nom de domaine : reprise d'application existante.
Ce que nous faisons, dans l'ordre
La reprise en trois temps : cadrer, stabiliser, reconstruire. Tout commence par un bilan de santé : en deux semaines, vous savez ce que l'application vous coûte et ce qui va casser en premier.
-
Cadrer
Nous lisons le code et l'hébergement, et nous cherchons les secrets exposés, les données en double et les dépendances à risque.
Le bilan de santé -
Stabiliser
D'abord le correctif urgent, par exemple sortir les secrets du code, puis ce qui rapporte le plus, au forfait. Chaque correction est livrée avec sa documentation.
Stabiliser -
Reconstruire
Seulement si garder l'application coûte plus cher que la reconstruire. Pas avant.
Reconstruire
Par où commencer ?
Votre application n'a pas été faite avec l'IA, mais plus personne n'y touche ? Voyez votre équipe n'a plus le temps, ou votre développeur est parti.
Toutes les situations : reprise d'application existante.