Vous avez créé votre outil avec l'IA. Voici ce qui va casser

Le fleuriste qui a fait son logiciel de commandes. L'artiste qui a monté sa plateforme de partage. Le kinésithérapeute qui gère ses rendez-vous avec son propre outil. Il y a trois ans, aucun d'eux n'aurait pu construire ça. Aujourd'hui c'est fait, ça tourne, et c'est souvent mieux pensé que ce qu'une agence leur aurait vendu, parce qu'ils connaissent le métier.

Le problème n'est pas là. Il commence le jour où d'autres personnes s'en servent. Construire une application et l'exploiter sont deux métiers différents : le premier a été démocratisé en deux ans, le second ne l'a pas été. C'est tout l'écart entre « ça marche » et « ça tient ».

Le terme vibe coding a été proposé par Andrej Karpathy le 2 février 2025 pour décrire une façon de développer où l'on décrit ce qu'on veut en langage naturel, où l'on accepte le code produit sans le relire en détail, et où l'on corrige par de nouvelles instructions plutôt qu'en lisant le code. Ce n'était pas une critique. C'est devenu une pratique de masse, et les conséquences se mesurent maintenant.

Ce que disent les mesures publiées

Le rapport GenAI Code Security 2025 de Veracode relève que 45 % des échantillons de code généré par IA contenaient au moins une vulnérabilité de l'OWASP Top 10, lorsqu'ils étaient examinés sans relecture humaine. Ce dernier point compte : la mesure porte sur du code accepté tel quel, ce qui est précisément la définition du vibe coding.

Les travaux publiés par les laboratoires de la Cloud Security Alliance sur des applications réellement déployées font état de fuites de secrets et de vulnérabilités à fort impact en nombre. Il ne s'agit pas d'exercices de laboratoire mais de code en ligne, utilisé par de vraies personnes.

Les six défaillances qu'on retrouve presque toujours

1. Les clés d'API en clair dans le dépôt

On le trouve dans presque tous les audits, et il est presque toujours sous-estimé. Les dépôts publics sont balayés en continu par des robots automatisés, et une clé poussée une fois reste dans l'historique même après suppression du fichier. Il faut la considérer comme compromise : la révoquer et la remplacer, pas seulement l'effacer.

2. L'absence totale de tests

Sans tests, personne ne sait ce qui casse quand on modifie une ligne. C'est ce qui produit l'application à laquelle plus personne n'ose toucher, et qui finit gelée alors qu'elle devrait évoluer. On commence toujours par les chemins qui touchent l'argent et les données personnelles, pas par la couverture globale.

3. Le coût par requête non plafonné

Spécifique aux applications qui appellent un modèle. Sans plafond par requête, par utilisateur et par mois, une boucle qui s'emballe ou un usage détourné produit une facture de fin de mois hors de proportion. Le plafond doit exister avant la mise en ligne, pas après le premier incident.

4. Aucune reprise après panne

Que se passe-t-il quand le modèle renvoie une erreur, quand la base ne répond plus, quand le fournisseur ralentit ? Dans une application générée rapidement, la réponse est en général : rien de prévu. Or ces trois cas ne sont pas rares, ce sont les conditions normales d'exploitation.

5. Ni journaux ni alertes

Vous apprenez la panne par un client, jamais autrement. Sans journalisation ni alerte, un incident peut durer des heures, et surtout devenir impossible à diagnostiquer après coup. C'est souvent la brique entièrement absente.

6. Des sauvegardes jamais restaurées

Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une hypothèse. Le jour où elle sert, on découvre qu'elle est incomplète, illisible, ou qu'elle date d'avant la dernière migration. La restauration se teste, en conditions réelles, au moins une fois.

L'ordre dans lequel traiter tout ça

Tout ne se vaut pas, et vouloir tout corriger en même temps est le meilleur moyen de ne rien livrer. L'ordre qui fonctionne suit l'irréversibilité des dégâts.

1. Les secrets d'abord. Une clé exposée peut déjà être utilisée contre vous à cet instant. C'est le seul point qui se traite dans l'heure.
2. Les sauvegardes ensuite. Parce que tout le reste devient rattrapable si vous pouvez revenir en arrière.
3. Les plafonds de coût. Ils vous protègent d'une facture pendant que vous travaillez sur le reste.
4. Les tests sur les chemins critiques. Argent et données personnelles en premier.
5. Les journaux et alertes. Pour cesser d'apprendre les pannes par vos clients.
6. La reprise après panne. Le plus long, et celui qui suppose que le reste tienne déjà.

Comment savoir où vous en êtes

Un audit passe ces points au crible et les classe en trois catégories : bloquant pour une mise en production, à surveiller, conforme. Le rapport doit être lisible par un dirigeant, pas seulement par un développeur, sinon il ne sert à rien.

Et il doit vous rester, y compris pour le faire exécuter par quelqu'un d'autre que nous. Un rapport qu'on ne peut pas emporter sert surtout à vendre la suite.

Vous avez une application à faire passer en production ?

Demander un audit