Votre app codée avec l'IA tourne. Mais est-elle prête pour la production ?

Mik Bry · 2026-07-22 · lecture ~9 min · IA · Sécurité

Votre app tourne. Les pages chargent, l'inscription fonctionne, le paiement s'affiche.

C'est une bonne nouvelle. Mais ça ne répond pas encore à la question qui compte avant la production : que se passe-t-il quand quelque chose sort du parcours prévu ?

Un paiement envoyé deux fois. Un identifiant modifié dans une URL. Une sauvegarde qu'on n'a jamais essayé de restaurer.

Je ne vais pas prétendre que l'IA est mauvaise pour écrire ou tester du code. Elle devient très bonne là-dessus. Le problème commence quand il faut décider si le risque qui reste est acceptable.

C'est là que je veux encore un humain responsable de la décision.

Une suite de tests vérifie des cas connus. Elle ne peut ni garantir tous les résultats en conditions réelles, ni décider si le risque restant est acceptable. À la fin, une personne identifiée doit encore assumer cette décision.

Dans une petite comparaison que j'ai menée entre des projets publics construits avec l'IA et des projets passés par ma propre revue, sur des tâches de taille comparable — surtout de petits services backend, rien d'exotique — presque aucun des projets publics ne se re-vérifiait automatiquement avant une mise en ligne. Les miens, si, systématiquement. L'écart se trouvait là où un fondateur ne peut rien voir en cliquant : est-ce que quelque chose aurait rattrapé un changement cassé en douce.

Cinq sujets où je veux encore une décision humaine

Toute mise en ligne ne mérite pas la même attention. Corriger une faute de frappe, ce n'est pas pareil que toucher à l'argent. Ces cinq endroits sont ceux où une erreur coûte cher ou devient difficile à annuler. Pour une version plus courte en six vérifications, voir Les 6 choses que je vérifie avant de mettre une app construite avec l'IA en production.

1. Les paiements

Facturé deux fois pour la même commande. Une carte débitée sans email de confirmation. Des clés live activées par erreur pendant un test. Rien de tout ça n'apparaît dans le seul paiement qu'on teste d'habitude. Quelqu'un a-t-il vraiment observé ce qui se passe quand un paiement échoue à mi-chemin ? La go-live checklist de Stripe existe justement parce que la plupart des équipes ne l'ont jamais fait. Si ça tourne mal, des clients sont facturés du mauvais montant, ou deux fois, et vous l'apprenez par un email furieux avant de le voir dans un tableau de bord.

2. Se connecter, et pouvoir revenir

Se connecter, c'est prouver qui on est à l'instant. Récupérer son compte, c'est prouver qu'on est toujours la même personne après avoir oublié son mot de passe — sans qu'un attaquant puisse faire pareil à sa place. J'ai vu des parcours de récupération qu'on croyait terminés parce que l'email de réinitialisation marchait une fois en démo, et que personne n'avait essayé de réinitialiser le compte d'un inconnu avec seulement ce qui est déjà public sur lui. Les Digital Identity Guidelines du NIST traitent la preuve d'identité, la sécurité des sessions et la récupération de compte comme une seule chaîne connectée, pas trois fonctionnalités séparées. Un écran de connexion solide avec une récupération fragile, c'est une porte blindée à côté d'un portail resté ouvert — la porte n'a jamais été le problème. Quelqu'un pourrait-il entrer dans le compte d'un autre aujourd'hui avec seulement ce qui est déjà public sur lui ? Si vous ne savez pas, voilà votre réponse.

3. Ce qu'un client peut voir d'un autre

Imaginez un ticket de support qui dit : « Je vois la facture de quelqu'un d'autre quand je change un chiffre dans l'adresse. » Ce n'est pas une hypothèse — c'est la chose la plus courante que je trouve. Une app peut savoir correctement qui est quelqu'un et quand même lui laisser voir les données de quelqu'un d'autre, si la vérification des droits manque sur ne serait-ce qu'une requête sur cent. L'Authorization Cheat Sheet de l'OWASP recommande de vérifier les permissions à chaque requête, pas seulement les évidentes — parce que ce sont rarement les évidentes qui cassent. Est-ce que quelqu'un a volontairement essayé d'ouvrir le compte d'un autre client et confirmé, par écrit, que ça avait échoué ? Protéger les données d'un client de celles d'un autre, c'est le volet accès d'une discipline plus large — Pourquoi mikbry.com n'a pas de bannière cookies couvre le volet collecte : ce qu'un site récolte sur ses visiteurs, et pourquoi en récolter moins est plus sûr.

4. Changer la base qui contient de vraies données

Pourriez-vous vraiment annuler ce changement ce soir, ou supposez-vous seulement que oui ? La plupart des équipes n'ont jamais testé la réponse — une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est un espoir. Les changements de base de données sont dangereux parce que l'ancien état a souvent disparu au moment où on remarque un problème — l'app continue d'écrire par-dessus. Le guide de migration de Google Cloud recommande de tester le changement d'abord, de sauvegarder la cible, et d'avoir un vrai plan pour tout remettre en place — pas seulement de croire qu'il existe. Si ça tourne mal, les données clients sont silencieusement corrompues, et la dernière sauvegarde jamais testée date de plusieurs heures.

5. Les clés qui mettent le code en production

Un ordinateur portable compromis, ou une clé API volée, pousse du nouveau code directement chez les clients. Personne de plus pour regarder, pas de délai, pas de retour arrière. C'est précisément le risque ici. Ça, c'est facile à rater. Et pourtant ça décide si les quatre points précédents veulent dire quoi que ce soit — si n'importe qui avec un ordinateur portable peut pousser directement en production, rien de tout ça ne compte. Les GitHub environments, par exemple, peuvent exiger l'approbation d'une deuxième personne avant qu'un déploiement ne s'exécute, et retenir les clés de production jusque-là. Des contrôles équivalents existent ailleurs ; la logique est la même. Une seule personne, ou un seul agent, pourrait-il pousser un changement en production tout seul, ce soir, sans que personne d'autre ne surveille ?

Une approbation ne suffit pas

Rien de tout ça ne se règle en collant un bouton d'approbation au bout d'un déploiement. Un relecteur pressé peut laisser passer une preuve faible aussi facilement qu'un agent peut la manquer. Une approbation de façade est pire que pas d'approbation du tout : elle met le nom de quelqu'un sur une décision que personne n'a vraiment prise.

L'approbation vaut quelque chose quand elle s'appuie sur un compte-rendu court et honnête, pas un rapport de cent pages que personne ne lit : ce qui change vraiment, quels cas ont été testés (y compris ceux censés échouer), qui pourrait être affecté si ça tourne mal, ce qui reste incertain, et comment tout annuler si ça part en vrille. C'est une page, pas un livre. Quelqu'un de nommé la lit, comprend ce qui reste incertain, et décide si le risque qui reste vaut la peine d'être pris.

Un Scan peut repérer des erreurs connues. C'est utile. Mais il ne peut pas décider si le risque qui reste est acceptable — c'est un jugement, pas un calcul. Le score est une preuve, pas une permission de lancer.

Avant d'appuyer sur le bouton, cinq questions à se poser honnêtement :

• Quelqu'un a-t-il testé ce qui se passe quand un paiement échoue à mi-chemin ?
• Un inconnu pourrait-il entrer dans le compte de quelqu'un d'autre avec seulement des informations publiques ?
• Quelqu'un a-t-il volontairement essayé d'ouvrir les données d'un autre client et confirmé que ça échouait ?
• Avez-vous vraiment testé une restauration de sauvegarde récemment, ou juste supposé que ça marcherait ?
• Une seule personne, ou un seul agent, pourrait-il pousser directement en production ?

Si l'une de ces réponses est « je ne sais pas », ce n'est pas une décision de mise en production. C'est un pari déguisé en décision.

Le lancement n'est que le début

Passer ces vérifications ne veut pas dire que le produit est terminé.

Ça veut simplement dire que vous avez évité de laisser vos premiers vrais utilisateurs découvrir à votre place certains risques que vous pouviez identifier avant.

Ensuite, la réalité commence.

Les utilisateurs vont faire des choses que vous n'aviez pas prévues. Un paiement va échouer dans un cas que personne n'avait testé. Une fonctionnalité secondaire va devenir importante. Une autre, peaufinée pendant une semaine, ne sera presque jamais utilisée. Les coûts vont bouger, les dépendances évoluer, le trafic arriver de façon irrégulière.

C'est normal.

Un produit qui fonctionne n'avance pas en ligne droite du prototype au lancement. C'est une boucle permanente : lancer, observer, apprendre, corriger, simplifier, puis relancer.

L'objectif avant la production n'est donc pas d'obtenir un produit parfait. C'est de comprendre les risques évidents, de maîtriser les plus dangereux et d'avoir assez de visibilité pour apprendre sans mettre le produit en danger.

Être prêt à lancer, c'est arriver en meilleur état sur la ligne de départ.

Après, le vrai travail produit commence.

Trust Report et Audit

Ces cinq sujets, c'est le volet sécurité et accès de la discipline. Pour le volet financier — ce qui fait vraiment grimper une facture après le lancement — Combien coûte une app construite avec l'IA ? couvre ça.

Trois niveaux : un Scan gratuit et automatisé, un Trust Report automatisé plus approfondi, puis un Audit qui combine mes outils avec une revue CTO humaine.

Avant de demander une revue CTO, vous pouvez commencer par le Launch Readiness Scan — il tourne en local, votre code source reste sur votre machine, et seuls les extraits que vous approuvez explicitement sont transmis. Il donne une première lecture automatique, mais ne voit ni votre environnement de production ni le contexte métier.