Lovable, Bolt, Cursor, ChatGPT : en quelques jours, parfois en quelques heures, vous avez une application qui fonctionne. Les écrans s’affichent, les formulaires s’enregistrent, la démo impressionne vos associés.
Puis vient la vraie question : est-ce que cette application tiendra avec 100 utilisateurs, des données réelles et une nouvelle fonctionnalité à ajouter dans six mois ?
Je relis régulièrement du code généré avec l’IA. Voici comment savoir où vous en êtes, sans lire une seule ligne de code.
Une application qui marche n’est pas une application solide
L’IA est excellente pour répondre à une demande précise : « ajoute un bouton », « crée une page de connexion ». Elle produit ce qui fonctionne maintenant. Mais elle n’a pas de vision d’ensemble : chaque demande est traitée isolément, et le code s’empile au fil des conversations.
Trois choses ne se voient pas pendant une démo :
- La sécurité : qui peut accéder à quoi, et ce qui se passe si quelqu’un essaie de forcer la porte.
- La structure : la facilité avec laquelle on pourra modifier l’application demain, sans tout casser.
- Les données : où elles sont stockées, comment elles sont protégées et si elles sont sauvegardées.
Ce sont pourtant ces trois points qui décident si votre application tiendra.
7 signes d’alerte à vérifier sans lire le code
Posez ces questions à la personne qui a construit l’application, ou à vous-même si c’est vous :
1. Personne ne sait expliquer comment l’application est organisée
Si la réponse à « comment est-ce construit ? » est « je ne sais pas, l’IA l’a fait », c’est le premier signal. Une application saine se décrit en quelques phrases : ses grandes parties, ce que fait chacune, où sont les données.
2. Chaque correction en casse une autre
Vous demandez à corriger un bug, et un autre apparaît ailleurs. C’est le symptôme d’un code où tout dépend de tout. Il s’aggrave à chaque modification.
3. Il n’y a aucun test automatique
Les tests automatiques vérifient, à chaque modification, que ce qui marchait marche toujours. Sans eux, chaque mise à jour est un pari. Demandez simplement : « combien de tests avons-nous, et quand ont-ils tourné pour la dernière fois ? »
4. Les clés d’accès sont écrites dans le code
Clés d’API, mots de passe de la base de données, accès au service de paiement : ils ne doivent jamais apparaître dans le code. S’ils y sont, toute personne qui accède au code accède aussi à vos services, et à vos factures.
5. On peut voir les données d’un autre utilisateur
Un test simple : connectez-vous avec un compte, ouvrez une fiche, puis changez le numéro qui apparaît dans l’adresse de la page. Si vous voyez la fiche d’un autre client, vous avez une fuite de données, et un problème de conformité RGPD.
6. Les sauvegardes n’ont jamais été testées
Une sauvegarde qu’on n’a jamais restaurée n’est qu’un espoir. La bonne question n’est pas « avons-nous des sauvegardes ? » mais « combien de temps pour tout remettre en ligne si le serveur disparaît ce soir ? »
7. Vous ne savez pas où est le code ni qui y a accès
Le code doit être dans un dépôt à votre nom, avec un historique des modifications. S’il est sur l’ordinateur d’un prestataire ou dans le compte d’un outil en ligne que vous ne contrôlez pas, votre application ne vous appartient pas vraiment.
Un scénario typique
Prenons un scénario typique. Il est fictif, mais chacun des problèmes qu’il décrit se retrouve couramment dans les applications générées avec l’IA.
Claire dirige une PME de services de 15 salariés. En trois semaines, avec un outil de génération par IA, elle construit un portail où ses clients consultent leurs devis et leurs factures. Tout fonctionne, les clients sont ravis.
Six mois plus tard, elle veut ajouter le paiement en ligne. Chaque modification casse autre chose : la connexion, puis l’affichage des factures. En cherchant pourquoi, une relecture du code révèle trois problèmes :
- en changeant le numéro dans l’adresse d’une facture, un client peut afficher celles des autres clients ;
- la clé d’accès au service de paiement est écrite en clair dans le code ;
- il n’existe aucune sauvegarde de la base de données.
Repérés à ce stade, ces trois points se corrigent en quelques jours. Découverts après une fuite de données, ils auraient coûté une notification à la CNIL, la confiance de ses clients et probablement une réécriture complète.
Ce que vous risquez vraiment
- Une fuite de données : obligations RGPD, notification à la CNIL, perte de confiance de vos clients.
- Une réécriture complète : quand le code est trop fragile, il coûte souvent moins cher de repartir de zéro que de le corriger.
- Une dépendance : à l’outil qui a généré le code, ou à la seule personne qui sait le faire tourner.
- Un blocage à la levée de fonds : les investisseurs font auditer le code. Une dette technique importante fait baisser la valorisation, voire échouer le tour.
Comment garder l’IA sans prendre de risque
L’IA n’est pas le problème : elle fait gagner un temps considérable. Le problème, c’est de lui laisser le volant. J’en parlais déjà dans l’IA dans le développement : mieux décider, mieux coder. Concrètement :
- Spécifier avant de générer : décrire ce que fait l’application, pour qui et selon quelles règles, avant de demander du code. C’est ce que j’enseigne dans la formation IA pour dirigeants.
- Faire relire le code régulièrement : une revue de code toutes les quelques semaines repère les dérives avant qu’elles coûtent cher. C’est le cœur de l’accompagnement.
- Partir d’un socle solide : connexion sécurisée, gestion des droits, tests et déploiement déjà en place. C’est le rôle de Maestyo, sur lequel je construis les applications sur mesure.
- Surveiller une fois en ligne : disponibilité, sauvegardes testées, mises à jour de sécurité. C’est ce que fait SerenIT.
Vitesse et qualité ne s’opposent pas, à condition de savoir où placer le curseur : c’est le sujet de qualité du code face au business.
Par où commencer ?
Si vous avez coché un ou plusieurs signes d’alerte, ne paniquez pas : la plupart se corrigent, à condition de les traiter tôt. Le plus simple est de faire relire votre application par un regard extérieur et indépendant.
Je propose un second avis sur votre application : le premier échange de 30 minutes est gratuit, et vous repartez avec une idée claire de ce qui doit être corrigé en priorité.
