Résumé

Ce simulateur de rollout pour code généré par IA montre quelle part de votre budget d’erreur sur 30 jours brûle un mauvais changement écrit par IA avant son rollback. Saisissez le trafic, le SLO, les paliers, le temps de soak et la vitesse de détection. Il compare un déploiement unique à 100%, un rollout progressif surveillé par un humain et un gate SLO automatisé, avec un calcul simple que vous pouvez vérifier à la main.

Planificateur de rollout gratuit

Simulez la propagation d’un code généré par IA avant le rollback

Le simulateur rollout code généré par IA calcule le budget d’erreur brûlé par un mauvais changement selon trois scénarios : déploiement unique, rollout progressif surveillé par un humain, et gate SLO automatisé. Saisissez votre trafic, votre SLO et vos paliers.

Lancer le simulateur Comprendre le calcul

Simulateur de rollout de code IA

Chaque champ modifie le résultat en direct. Les valeurs par défaut décrivent un service à 200 requêtes par seconde avec un SLO de 99.9% et un changement qui échoue sur 20% des requêtes.

Votre plan de rollout
PalierTraficDémarre àRequêtes servies par le nouveau code
Fonctionnement

Trois lignes de calcul, aucun modèle caché

Budget d’erreur

Budget = (1 moins SLO) fois les requêtes moyennes par seconde fois 2,592,000 secondes sur 30 jours. À 200 req/s et 99.9%, cela fait 518,400 requêtes en échec autorisées par mois.

Exposition dans le temps

Le palier donne la part du trafic reçue par le nouveau code à chaque minute. Le simulateur intègre cette part depuis la première requête jusqu’au délai de détection plus le délai de rollback. Une détection lente pousse donc le changement vers des paliers plus gros.

Requêtes en échec

Échecs = requêtes par seconde fois la part d’échec fois l’intégrale d’exposition. Diviser par le budget donne le pourcentage du mois consommé par un seul mauvais changement. Trois modes de détection sont comparés sur le même palier.

Utilisation sur un vrai changement

D’un diff généré par IA à un plan de rollout

  1. 1

    Choisissez des entrées pessimistes

    Pour un changement écrit par un générateur de code IA et relu trop vite, supposez une part d’échec élevée s’il est mauvais, et un délai de détection égal à votre incident récent le plus lent, pas au meilleur.

  2. 2

    Comparez les trois scénarios

    Le déploiement unique montre le pire cas. Le cas progressif avec humain montre ce que votre palier vous apporte aujourd’hui. Le gate automatisé montre ce qu’un gate sur votre métrique SLO changerait.

  3. 3

    Copiez le plan dans le runbook

    Le bouton de copie exporte les paliers et le pire cas de consommation du budget en texte brut, prêt à coller dans un ticket de changement ou une description de pull request.

Pourquoi le palier compte

Le premier palier est celui qui économise l’essentiel du budget

Un changement qui échoue sur 20% des requêtes à 1% du trafic produit des échecs sur 0.2% des requêtes. Le même changement à 100% fait échouer une requête sur cinq. L’écart entre ces deux chiffres est tout l’argument d’un rollout progressif. Quand le code vient d’un générateur capable de produire des centaines de lignes en quelques secondes, le temps de revue par ligne baisse, et le premier palier devient l’endroit où l’on découvre le problème.

  • Un premier palier à 1% réduit le rayon d’impact de 99% avant toute mesure.
  • Le temps de soak ne sert que si votre signal peut montrer une régression dans cette fenêtre.
  • Revenir en arrière plus vite compte autant que détecter plus vite : les deux allongent l’intégrale d’exposition.
Baie serveur avec une seule lampe de statut orange parmi les vertes
Lire le résultat

Que faire des trois chiffres

Déploiement unique

Si ce chiffre dépasse 5% du budget mensuel pour une panne plausible, un déploiement en une fois revient à dépenser votre budget sur un seul changement. Peu d’équipes font ce choix délibérément.

Progressif, humain

C’est votre réalité actuelle si l’astreinte surveille les graphiques. Si l’exposition max affiche 100%, votre palier est décoratif : le mauvais changement atteint tout le monde avant que quelqu’un réagisse.

Progressif, gate automatisé

C’est le cas pour un gate qui lit votre métrique SLO et revient en arrière sans demander. La valeur n’est réelle que si le gate se déclenche sur le même signal que votre SLO, donc testez-le avec un changement volontairement mauvais.

Questions fréquentes

Ce simulateur de rollout pour code généré par IA est-il gratuit ?
Oui. Il tourne entièrement dans votre navigateur, ne demande aucune inscription et n’envoie rien à un serveur, hormis un signal anonyme d’usage. Ce n’est pas un générateur de code IA : il simule la propagation d’un mauvais changement une fois que du code issu d’un générateur atteint votre pipeline.
D’où viennent les chiffres ?
D’un calcul que vous pouvez vérifier à la main. Le budget d’erreur est (1 moins votre SLO) fois les requêtes sur 30 jours. Les requêtes en échec sont votre trafic fois la part d’échec fois la part de trafic reçue par le nouveau code, intégrée jusqu’à la fin du rollback. Aucun benchmark n’est intégré : chaque hypothèse est une entrée.
Pourquoi modéliser le code généré par IA différemment du code écrit à la main ?
Le calcul est identique. Ce qui change, c’est le prior : un gros diff produit en quelques minutes a reçu moins de revue humaine par ligne, donc la part d’échec et le délai de détection méritent des valeurs pessimistes. Calibrez-les sur votre propre historique d’incidents, pas sur cette page.
Que suppose le simulateur que le trafic réel ne fait pas ?
Il suppose un trafic stable, une régression qui fait échouer la même part de requêtes dès la première requête, et un rollback qui arrête les dégâts dès qu’il est terminé. Les vrais incidents ont une montée en charge, des pannes partielles et des rollbacks lents : traitez le résultat comme un plancher des dégâts, pas comme une prévision.
Quel est un bon délai de détection pour un gate SLO automatisé ?
Cela dépend de la résolution de vos métriques et de la fenêtre d’alerte. Un gate qui compare un taux d’erreur sur une minute à un seuil peut se déclencher en deux à cinq minutes. Si votre alerting ne déclenche qu’après une fenêtre de burn rate de 30 minutes, saisissez cette valeur à la place, et le simulateur montrera ce qu’elle coûte.
Un temps de soak plus long aide-t-il toujours ?
Non. Un soak plus long donne plus de données au gate à chaque palier, mais maintient aussi un mauvais changement à une part de trafic donnée plus longtemps. Si le gate détecte en moins de deux minutes, un soak de dix minutes ajoute surtout de l’attente. S’il lui faut quinze minutes, un soak de cinq minutes laisse le changement atteindre 25% ou plus avant.
Peut-on l’utiliser pour des rollouts de feature flags et pas seulement pour des déploiements ?
Oui. Un rollout en pourcentage d’un flag se comporte comme un déploiement canary pour ce calcul : une part de trafic, un temps de soak, un délai de détection et un délai de rollback. Remplacez le délai de rollback par la latence de votre kill switch de flag.

Vous voulez que le gate fasse le rollback à votre place ?

upstreamapi exécute des rollouts progressifs avec gates SLO et rollback automatique, donc la troisième colonne est celle avec laquelle vous livrez.

Découvrir upstreamapi