Vous faites convertir un lot de documents par un agent. Il a préparé son environnement et produit un fichier intermédiaire lorsque la session s'arrête. Au retour, vous souhaitez retrouver ce fichier, puis terminer le travail sans recommencer les étapes déjà validées. Deux questions se posent : quels fichiers pouvez-vous restaurer, et comment l'application sait-elle ce qui reste à faire ?
Le 30 septembre 2026, Cloudflare a annoncé des évolutions de Containers : choix de l'image et des ressources au démarrage, et captures du système de fichiers en bêta publique. Elles passent par une nouvelle politique de planification pilotée depuis un Durable Object, un composant qui conserve un état hors du conteneur. Cloudflare publie également des gains de démarrage issus de ses conditions de mesure. Ils ne constituent pas un résultat pour votre application. Annonce Cloudflare.
La distinction utile est simple : retrouver un espace de travail ne prouve pas que la tâche reprend correctement. Voici comment préparer un pilote qui vérifie les deux. Les documents, identifiants et situations ci-dessous sont fictifs ; aucun essai Cloudflare n'a été exécuté pour cet article.
Ce que vous cherchez à retrouver
Un conteneur est un environnement isolé dans lequel vous lancez vos outils. Son image décrit les fichiers et logiciels de départ. Une capture du système de fichiers, souvent appelée snapshot, conserve un état des fichiers. Le processus qui exécutait une commande, lui, possède aussi un état en mémoire, des connexions et parfois des opérations en cours auprès d'autres services.
Ne supposez pas que ces éléments reviennent avec les fichiers. Pour notre transformation documentaire, séparons quatre responsabilités :
| Élément fictif | Où le conserver dans le pilote | Vérification attendue |
|---|---|---|
| Texte intermédiaire du document | Espace de travail capturé | Empreinte du fichier identique après restauration |
| Version de l'outil de conversion | Environnement préparé et manifeste | Version retrouvée et compatible avec le fichier |
| Dernière étape acceptée | Journal applicatif extérieur | Étape reconnue avant de reprendre |
| Autorisation d'accès au document | Gestion des droits actuelle | Droit encore valide au moment du redémarrage |
Le choix du stockage du journal est une décision d'architecture du pilote. Il ne faut pas le déduire du seul fait qu'un snapshot existe. Un fichier « résultat terminé » peut avoir été écrit avant que la tâche soit acceptée ; inversement, le service extérieur peut avoir reçu un résultat avant que le conteneur ait enregistré la confirmation.
Dessiner la reprise avant de programmer
Prenez une seule opération : produire un résumé en brouillon à partir d'un document synthétique. Associez une identité à la tâche, au document source et à la version de son contenu. Puis consignez chaque étape acceptée. Un journal possible distingue « entrée vérifiée », « texte intermédiaire prêt », « résumé prêt pour relecture » et « tâche clôturée ».
La capture doit correspondre à un point cohérent. Si vous capturez pendant qu'un outil écrit, le fichier restauré peut ne pas être le résultat complet attendu. Le pilote peut donc attendre la fin de l'étape, fermer les fichiers utiles, relever leurs empreintes puis capturer l'environnement. Ce protocole doit être testé ; ce n'est pas une garantie attachée automatiquement au mot snapshot.
Après restauration, l'application relit le manifeste et le journal. Elle vérifie que le document, la version de l'outil et la dernière étape correspondent. Si le fichier est absent ou incohérent, elle reprend depuis une étape sûre au lieu d'avancer sur une hypothèse. Si les droits ont été révoqués, elle arrête la tâche même si les anciens fichiers sont toujours présents.
Rejouer sans publier deux résultats
Une opération est dite idempotente lorsque sa répétition ne crée pas un effet supplémentaire indésirable. Dans notre exemple, la clé du résumé peut associer la tâche, le document et sa version. Deux tentatives de reprise doivent alors retrouver le même brouillon ou signaler un conflit, au lieu de créer deux éléments indépendants.
Cette précaution compte aussi lorsqu'une connexion se coupe après l'envoi du résultat. L'agent ne sait pas toujours si le destinataire l'a accepté. Le journal et la clé de l'opération servent à lever cette ambiguïté. Le choix exact dépend de votre système ; un snapshot de fichiers ne règle pas à lui seul la coordination avec un service extérieur.
Mesurer le moment où le travail devient possible
Vous pouvez démarrer un conteneur rapidement et attendre longtemps avant de disposer du document. Distinguez trois durées dans le protocole : demande de démarrage jusqu'à disponibilité du processus, préparation de l'environnement jusqu'à disponibilité des outils, puis reprise jusqu'à la première étape utile acceptée.
Le temps utile doit inclure les vérifications du manifeste, les nouveaux droits et le chargement des données. Sinon, une accélération du lancement masque un travail déplacé plus loin. Comparez des tâches identiques, avec les mêmes documents synthétiques et les mêmes outils.
| Scénario à essayer | Observation à consigner | Résultat à renseigner après essai |
|---|---|---|
| Démarrage neuf | Installation et chargement des outils | Non mesuré |
| Restauration après étape validée | Fichiers et journal cohérents | Non testé |
| Arrêt pendant écriture | Rejet du fichier incomplet ou reprise sûre | Non testé |
| Deux reprises concurrentes | Un seul brouillon accepté | Non testé |
| Droit révoqué entre deux sessions | Arrêt et absence de nouvel accès | Non testé |
La durée, le coût et le taux de reprise correcte répondent à des questions différentes. Une restauration rapide qui laisse un document incomplet n'est pas une amélioration. Conservez les échecs dans la comparaison, y compris le temps humain de diagnostic. Aucun chiffre du fournisseur ne remplace ces observations.
Préparer un espace de travail qui peut être conservé
Un environnement temporaire peut contenir des fichiers que vous ne souhaitez pas garder : jetons, caches de requêtes ou copies de documents. La capture peut prolonger leur présence. Pour ce pilote, utilisez uniquement des données synthétiques et vérifiez la liste des fichiers avant de créer un état réutilisable.
La séparation des espaces de travail doit suivre les identités des utilisateurs et des tâches. Évitez de restaurer un espace préparé avec les fichiers d'un client pour le travail d'un autre. Les accès actuels restent une condition de reprise, et les identifiants sensibles doivent être obtenus selon les droits actuels plutôt que récupérés dans un ancien fichier de configuration.
Fixez également une durée de conservation. À la clôture, décidez ce qui est supprimé, ce qui est gardé pour expliquer le résultat et qui peut y accéder. Prévoyez l'expiration des tâches abandonnées et un plafond du nombre d'environnements. Ces règles appartiennent à votre application et doivent être observables.
Décider à partir d'un pilote borné
Commencez par un lot synthétique, un outil, une étape intermédiaire et une opération de sortie réversible. Avant l'essai, écrivez les critères d'acceptation : fichiers cohérents, droits revérifiés, absence de résultat en double, temps utile mesurable et coût explicable. Une seule condition échouée doit produire une décision explicite de correction ou d'arrêt.
Préparez aussi la sortie du pilote. Conservez les documents sources et le journal dans des formats exploitables sans dépendre du snapshot. Une nouvelle exécution depuis les sources doit rester possible si une capture devient inutilisable. Pour les principes de continuité et les tests de restauration, notre guide sur le PRA et le PCA d'une application web complète cette démarche.
La prochaine étape est de provoquer volontairement l'arrêt au point intermédiaire, puis de contrôler la reprise. Vous observerez alors ce que votre application restaure, ce qu'elle doit recalculer et ce qu'elle ne doit plus accéder. La capacité de conserver des fichiers fournit une brique utile ; la preuve recherchée reste celle d'un travail repris correctement.
Source et date de référence
Cloudflare — Cloudflare Containers, rebuilt to scale agent sandboxes, annonce du 30 septembre 2026, consultée le 1er octobre 2026. Les capacités et le statut bêta sont attribués à l'éditeur ; les tableaux et le protocole sont des propositions Partitech sans résultats de test.