Un code corrigé n'est pas forcément un site mis à jour. Un agent peut modifier les fichiers, réussir les vérifications et tout enregistrer pendant votre sommeil. Si la mise en ligne est bloquée, les visiteurs voient toujours l'ancienne version.
1. Tout est « terminé », sauf le résultat visible
Avant de dormir, vous demandez un nouveau design, des emplacements publicitaires et la mise en ligne de pages traduites. Le lendemain, le rapport annonce fièrement : modifications terminées, contrôles effectués, fichiers enregistrés.
Vous ouvrez le site. L'ancien bouton est toujours là. L'IA a travaillé de nuit ; le site a raté son réveil.
Il faut distinguer la création, l'enregistrement, la mise en ligne et la vérification sur la page publique. Pour le lecteur, seul le dernier point prouve que le changement est arrivé.
2. L'entrepôt est plein, mais le quai de livraison est fermé
Le dépôt de code conserve les changements. Un autre système les publie. Les deux peuvent rencontrer des problèmes différents. Publier un nouvel article et remplacer le programme du site empruntent parfois des chemins distincts.
On peut donc voir apparaître des articles récents alors que le design reste ancien. Des milliers de traductions validées attendent leur tour. Une publicité corrigée dans le code demeure invisible aux visiteurs.
Un seul passage bloqué suffit à immobiliser une montagne de travail terminé.
3. Deux plafonds gratuits qu'il ne faut pas confondre
En octobre 2026, l'offre gratuite de Cloudflare comprend 3 000 minutes de Workers Builds par mois, tandis que Workers autorise 100 000 requêtes par jour.[1][2]
Le premier plafond concerne la fabrication et le déploiement d'une nouvelle version. Le second concerne le trafic traversant le programme déjà en service. Ce sont deux problèmes distincts.
Si le budget de fabrication est épuisé, on limite les relances inutiles et on prévoit une autre voie autorisée. Si les requêtes sont trop nombreuses, on réduit le passage des fichiers et pages simples par le Worker. Réparer les fourneaux ne désengorge pas automatiquement l'entrée du restaurant.
4. Relancer une erreur jusqu'à épuiser son forfait
Une compilation échoue. On relance sans lire le message d'erreur. Elle échoue encore. Les minutes gratuites disparaissent.
Dix rapports d'incident, aucune amélioration en ligne. Félicitations : une usine à rapports d'échec vient d'ouvrir.
Mieux vaut analyser le journal, reproduire le problème sur son ordinateur si possible, corriger sa cause puis relancer. La modification d'un simple texte ne devrait pas exiger systématiquement la reconstruction complète du site. Une tâche en panne ne doit pas immobiliser les autres publications sûres et indépendantes.
5. Confier à l'IA la réparation du chemin, pas seulement du code
Un bon agent de nuit distingue ce qui est vraiment en ligne, ce qui reste bloqué, la cause du blocage et ce qui a avancé ailleurs. Dans le cadre de ses autorisations, il peut poursuivre la réparation jusqu'à la livraison.
Plusieurs services de déploiement offrent une solution de secours, mais ils doivent partager la même version de référence. Sinon, un outil risque de publier une vieille version au-dessus de la nouvelle. Les clés secrètes et les autorisations du compte restent sous le contrôle de leur propriétaire.
La preuve finale consiste à ouvrir la page publique et constater le changement.
6. Le vrai bilan du matin
Mesurez les changements réellement visibles, les échecs récupérés et les pannes répétées évitées plutôt que le nombre de fichiers retouchés pendant la nuit.
L'humain a l'idée, puis dort. L'IA corrige, dépanne, publie et vérifie.
Le plus beau message du matin n'est pas « J'ai beaucoup travaillé ».
C'est : « Vous pouvez regarder, le site est à jour. »
