Avec l’IA, le vrai danger est parfois de croire trop tôt que « c’est fini »
Une IA peut transformer une idée en appli multijoueur fonctionnelle à une vitesse assez ridicule. La salle se crée, les gens entrent, publient et votent. Le cerveau annonce :
Terminé.
Le serveur répond :
Tu as testé avec une seule personne.
Les vraies questions arrivent ensuite. Que se passe-t-il si 100 personnes agissent en même temps ? Si l’écriture en base réussit mais que la réponse de succès disparaît ? Si le dernier vote arrive exactement à l’échéance ? Si une notification de paiement arrive deux fois ? Si tout le monde se reconnecte au même instant après une panne ?
La revue de code d’une petite application multijoueur a fini par produire 324 cas de test. Cela ne veut pas dire 324 bugs trouvés. Les 324 tests étaient encore à exécuter. C’était un plan, pas un certificat.
1. Le DDoS n’est pas le seul moyen de saturer une appli
Cloudflare fournit une mitigation DDoS automatique sur tous les forfaits, mais recommande aussi des protections applicatives comme le rate limiting, car une grosse attaque peut toujours affecter l’application.[1]
Pour un petit projet, le trafic légitime peut suffire à créer le premier problème.
Avec un polling toutes les trois secondes :
| Clients simultanés | Vérifications par heure |
|---|---|
| 10 | 12 000 |
| 30 | 36 000 |
| 100 | 120 000 |
| 1 000 | 1 200 000 |
Ce n’est pas une prévision de capacité réelle. Le backoff et le cache peuvent réduire ces chiffres ; les publications, images, boîtes de réception, onglets multiples et tâches planifiées peuvent les augmenter.
Au 5 octobre 2026, Workers Free indique 100 000 requêtes par jour. D1 Free indique 5 millions de lignes lues par jour, 100 000 lignes écrites, 500 Mo par base et 50 requêtes SQL par invocation Worker.[2][3] Une base D1 traite les requêtes une par une ; trop de concurrence crée une file et peut finir par une erreur de surcharge.[3]
Le scénario inquiétant n’est donc pas forcément « un million d’attaquants ».
Cent vrais utilisateurs qui s’amusent en même temps peuvent déjà constituer un test de charge.
2. Pourquoi la liste est montée à 324 tests
Les 16 domaines couverts étaient : entrées et abus, capacité, concurrence et reprise, tâches planifiées, salles et droits, images, texte, vote, échéances, résultats, salles publiques, connexions persistantes, appareils et reconnexion, intégrations, paiement, déploiement et monitoring.
Tout ne se traite pas avec la même priorité.
3. Les 23 points à attaquer en premier
- Une requête rejetée déclenche-t-elle quand même un travail DB coûteux ?
- Le compteur interne mesure-t-il vraiment toutes les routes coûteuses ?
- La limitation survit-elle aux redémarrages et à plusieurs instances ?
- Un polling « aucun changement » lit-il quand même beaucoup de données ?
- Une seule place peut-elle ouvrir des connexions persistantes illimitées ?
- HTTP et connexion persistante appliquent-ils les mêmes limites ?
- Un arrêt d’urgence coupe-t-il aussi les clients déjà connectés ?
- Un retard du planificateur laisse-t-il passer une action après l’échéance ?
- Un effet peut-il échouer pendant que la salle continue d’avancer ?
- Une réparation relancée peut-elle compter deux fois des statistiques ?
- Une réservation de départ peut-elle être consommée avant la création réelle de la partie ?
- Un retry peut-il transformer une réponse en deux ?
- Des variantes visuelles d’un pseudo contournent-elles l’unicité ?
- Deux personnes peuvent-elles prendre la dernière place ?
- Les tâches planifiées peuvent-elles accumuler plus de travail qu’elles n’en traitent ?
- Mesure-t-on toute la base et les index, pas seulement les images ?
- Quelqu’un peut-il reprendre l’identité d’un appareil perdu ?
- Format, dimensions, métadonnées et géolocalisation des images sont-ils contrôlés ?
- Un long historique rend-il chaque affichage de plus en plus cher ?
- Les reconnexions synchronisées peuvent-elles créer une deuxième panne ?
- Paiements dupliqués, retardés, échoués, annulés et restaurés ont-ils été testés ?
- Confond-on réussite locale et garantie en production ?
- Si la base tombe, le système de surveillance tombe-t-il avec elle ?
4. Les bugs aiment les combinaisons
Scénario utile :
100 personnes votent → 20 actualisent → 10 perdent la connexion → certaines écritures réussissent mais la réponse disparaît → retry.
On vérifie ensuite les doubles votes, votes tardifs, retours vers un ancien état et opérations exécutées deux fois.
OWASP traite d’ailleurs les sessions concurrentes, les entrées anormales et la gestion des erreurs comme des sujets de test distincts.[4]
5. « Enregistré » et « l’utilisateur a reçu OK » sont deux événements
Le serveur peut enregistrer correctement alors que la réponse réseau disparaît.
L’utilisateur voit un échec et recommence.
Sans identifiant d’opération ou déduplication, on peut obtenir deux réponses, deux salles, deux votes, deux notifications ou deux paiements.
Le retry doit être conçu.
6. Le test de charge se fait par paliers
Dans un environnement contrôlé : 10 → 30 → 100 clients.
Puis on change la forme : une salle très chargée, beaucoup de salles, arrivées simultanées, dernier vote simultané, reconnexion massive, tâches planifiées et panne de stockage simulée.
On n’envoie pas volontairement de trafic massif vers un système tiers ou non autorisé. Budget et conditions d’arrêt sont définis avant le test.
7. « Ça n’a pas planté » n’est pas un critère suffisant
On peut viser 95 % des requêtes ordinaires sous une seconde, 99 % sous trois secondes et moins de 0,1 % de 5xx inattendus.
Mais certaines choses doivent rester à zéro :
- fuite de données d’un autre utilisateur ;
- action sans autorisation ;
- score doublé ;
- donnée confirmée perdue ;
- double facturation.
8. Plan de test 9/10, preuve exécutée 0/10
Une liste de 324 cas avec 23 risques prioritaires peut être excellente.
Avant exécution, la preuve reste pourtant à zéro.
Ce n’est pas un échec : le projet est passé de « je ne sais pas quoi tester » à « je sais précisément où essayer de le casser ».
9. Puis une autre limite peut casser : le quota hebdomadaire de l’IA
Une journée entière à faire lire un gros dépôt à une IA, implémenter, corriger, relire puis recommencer peut épuiser le quota IA avant le serveur.
Au 5 octobre 2026, Claude Max 20x coûte 200 $ par mois sur le web. Le « 20x » correspond à la capacité par session par rapport à Pro. La limite de session se réinitialise toutes les cinq heures, mais Max possède aussi une limite hebdomadaire partagée entre les modèles.[5]
20x ne veut donc pas dire illimité.
La consommation dépend du modèle, du contexte et de la tâche ; Settings > Usage reste la référence.
10. « Fable est cher » tient aussi face aux chiffres
Sur Max, Fable 5 et 5.1 sont disponibles, mais Fable peut consommer jusqu’à 50 % de la limite hebdomadaire et Anthropic précise qu’il épuise cette capacité plus vite que les autres modèles Claude.[6]
| Modèle | Entrée / 1M tokens | Sortie / 1M tokens |
|---|---|---|
| Sonnet 5.5 | 2 $ | 10 $ |
| Opus 5.5 | 4 $ | 20 $ |
| Fable 5.1 | 10 $ | 50 $ |
Fable 5.1 coûte 2,5 fois le prix d’Opus 5.5 en entrée comme en sortie. Les lectures de cache moins chères réduisent le coût par rapport à Fable 5, mais le prix absolu reste élevé.[6][7][8]
Le tarif API ne se convertit pas directement en minutes de quota Max, mais la logique reste la même : faire tourner longtemps le modèle le plus lourd coûte cher.
11. Pas besoin d’une grue pour chaque vis
Sonnet 5.5 : corrections courantes, bugs compris, modifications répétitives, tâches bien cadrées.
Opus 5.5 : cause inconnue, architecture, revue multi-fichiers, décision importante avant mise en ligne.
Fable 5.1 : tâches les plus difficiles lorsque le gain de capacité justifie le coût ou la consommation de quota.
Ce n’est pas un classement. C’est de l’ingénierie du coût par tâche.
12. L’IA ne supprime pas le goulot d’étranglement, elle le déplace
Avant : idée → plusieurs semaines de développement → tests.
Maintenant : idée → implémentation rapide → tests, exploitation, quotas serveur et quotas IA arrivent ensemble.
« J’ai fait l’appli en une journée » peut être vrai.
Formulation plus précise :
« En une journée, je suis arrivé au stade où je peux enfin essayer de la casser sérieusement. »
C’est là que la préparation à la production commence.
Références (8)
- Cloudflare DDoS developers.cloudflare.com
- Cloudflare Workers developers.cloudflare.com
- Cloudflare D1 developers.cloudflare.com
- OWASP WSTG wstg.owasp.org
- Anthropic Max support.claude.com
- Anthropic Fable support.claude.com
- Opus 5.5 anthropic.com
- Sonnet 5.5 anthropic.com
