Les environnements cloud d’OpenAI Codex font sortir le travail de codage du cadre de l’ordinateur portable

Les environnements cloud d’OpenAI Codex permettent désormais aux développeurs de préparer une fois un espace de travail réutilisable, puis d’envoyer des tâches de codage depuis plusieurs appareils. Ce changement supprime une contrainte persistante du codage agentique : l’ordinateur portable n’a plus besoin de rester ouvert pendant que l’agent travaille.

OpenAI a annoncé cette mise à jour le 29 septembre 2026, aux côtés d’autres évolutions de Codex lors de sa conférence DevDay. Son publication destinée aux développeurs présente les environnements cloud comme un moyen de réduire les configurations répétitives et de garder le travail accessible sur différents appareils.

Le changement important ne tient pas simplement au fait que Codex s’exécute sur des ordinateurs distants. GitHub Copilot, Google Jules et Claude Code prennent déjà en charge diverses formes de développement cloud asynchrone. OpenAI transforme plutôt l’environnement de développement préparé en une couche produit réutilisable.

Cette distinction change la question concurrentielle. Les agents de codage ne rivalisent plus uniquement sur leur capacité à produire le meilleur correctif. Ils rivalisent sur leur capacité à conserver suffisamment de contexte projet, d’outillage, d’accès et d’état de travail pour accepter immédiatement la tâche suivante.

Ce que les environnements cloud d’OpenAI Codex changent réellement

La mise à jour dissocie l’espace de travail de codage d’un développeur de l’ordinateur qui se trouve actuellement devant lui.

Un environnement cloud Codex est une configuration enregistrée qui contient des dépôts, des dépendances, des outils, des scripts et des paramètres d’accès. OpenAI indique que Codex peut inspecter les dépôts sélectionnés, installer les logiciels nécessaires, tester la configuration et demander les informations manquantes.

Les développeurs examinent cet environnement préparé avant de le publier. Les nouvelles tâches peuvent ensuite démarrer depuis cette configuration publiée, au lieu de reconstruire le projet sur une machine vierge.

Ce processus répond à une faiblesse bien connue des agents de codage distants. Lancer un agent est simple lorsqu’un dépôt ne nécessite qu’un environnement d’exécution standard et une commande d’installation. Cela devient plus difficile lorsque le projet dépend de versions précises d’outils, d’assets générés, de paquets privés ou de services de soutien.

Un environnement réutilisable déplace ce travail de configuration plus tôt dans le processus. Le développeur prépare et valide l’espace de travail avant d’assigner des tâches importantes.

OpenAI enregistre le comportement d’installation et de démarrage à l’aide de deux composants centraux. Un script d’installation prépare les dépendances et les assets de développement, tandis qu’une compétence de démarrage explique comment lancer les services et vérifier qu’ils sont prêts.

Selon le guide des environnements, la publication capture le système de fichiers préparé pour les tâches futures. Chaque nouvelle tâche reçoit néanmoins son propre espace de travail isolé, ce qui limite les interférences entre affectations distinctes.

Les tâches existantes se comportent différemment des nouvelles. Elles conservent leurs propres fichiers enregistrés, outils installés et modifications non validées. Une actualisation du dépôt peut s’exécuter en arrière-plan tout en préservant les caches de dépendances.

Cette séparation compte lorsque les développeurs mettent à jour un environnement. Les paramètres republiés s’appliquent aux nouvelles tâches, tandis qu’une tâche existante poursuit son travail avec son état précédent. Cette conception favorise la continuité, mais elle oblige aussi les utilisateurs à comprendre quelle version de l’environnement une tâche a héritée.

La deuxième partie de l’annonce concerne l’accès. Les développeurs peuvent démarrer un travail cloud depuis l’application web ou de bureau, puis rouvrir la même tâche ailleurs.

L’accès mobile ne signifie pas qu’un téléphone devient une machine de développement. Il devient une interface de contrôle pour sélectionner un environnement, lire l’avancement, examiner les résultats et donner des instructions complémentaires.

OpenAI indique qu’une tâche cloud peut se poursuivre alors que l’ordinateur de l’utilisateur est en veille. C’est une frontière plus significative que la simple fermeture d’un onglet d’éditeur, car l’exécution ne dépend plus de l’appareil d’origine.

La vue d’ensemble de Codex cloud souligne également le travail parallèle. Chaque affectation longue peut recevoir un environnement dédié pendant que le développeur poursuit une autre tâche ou examine un résultat antérieur.

Le bénéfice immédiat est une attente réduite liée à la configuration. Le changement plus profond est opérationnel : le travail dans Codex devient une activité au niveau du compte, capable de survivre aux changements d’appareil, aux redémarrages locaux et aux périodes d’absence de l’utilisateur.

Pourquoi une configuration réutilisable compte davantage que l’exécution distante

L’exécution distante économise du temps machine, mais une configuration réutilisable préserve l’attention des développeurs.

Exécuter du code sur une machine hébergée n’est pas nouveau. Les services d’intégration continue le font depuis des années, et plusieurs agents de codage travaillent déjà dans des environnements isolés distants.

La partie coûteuse est souvent la distance entre le clonage d’un dépôt et l’obtention d’un état de développement fiable. Cet écart inclut l’installation des paquets, le choix de l’environnement d’exécution, la préparation de la base de données, l’authentification et le démarrage des services.

Un développeur humain accumule ces connaissances avec le temps. Son ordinateur portable contient des outils installés, des dépendances en cache, une configuration shell et des correctifs non documentés qui permettent au projet de fonctionner.

Un agent de codage isolé n’hérite pas automatiquement de cet environnement. Si chaque tâche démarre dans un environnement vierge, l’agent passe à plusieurs reprises du temps à redécouvrir les mêmes exigences.

Expliqués en termes pratiques, les environnements cloud Codex répondent à cette répétition. L’environnement devient un point de départ réutilisable, tandis que chaque tâche reçoit des fichiers de travail distincts.

Prenons une équipe qui maintient une application web avec une interface, une API et du code client généré. Un simple bogue peut nécessiter plusieurs environnements d’exécution, un registre de paquets et deux services locaux.

Sans environnement préparé, l’agent peut échouer avant même de traiter le bogue. Il peut choisir le mauvais gestionnaire de paquets, manquer une étape de génération ou ne démarrer qu’un seul service requis.

Avec un environnement publié, ces exigences peuvent être installées et testées à l’avance. La tâche commence plus près du point où le raisonnement sur le code devient utile.

Ce modèle crée aussi une séparation plus claire entre la maintenance de l’environnement et le travail sur les fonctionnalités. Une équipe peut mettre à jour la configuration partagée lorsque les dépendances changent, puis la republier pour les tâches ultérieures.

Cependant, la réutilisation n’élimine pas la dérive de configuration. Les tâches existantes conservent leur état antérieur, tandis que les nouvelles tâches reçoivent l’environnement mis à jour. Les équipes ont toujours besoin de contrôle de version, de scripts reproductibles et d’une responsabilité claire concernant les changements d’environnement.

OpenAI avertit explicitement que l’état enregistré ne remplace pas le contrôle de version. Le travail important doit toujours être validé ou exporté via le processus de développement habituel.

L’environnement ne contient pas non plus toutes les personnalisations personnelles. Les compétences basées sur le dépôt sont disponibles pour les tâches cloud, mais les compétences personnelles stockées sur l’ordinateur local d’un développeur ne se synchronisent pas automatiquement.

Cette limite révèle la frontière visée par le produit. OpenAI conditionne l’état de préparation au niveau du projet, sans cloner dans le cloud l’ensemble du poste de travail d’un développeur.

Pour les équipes d’ingénierie, la question pratique est de savoir si les connaissances du projet peuvent devenir suffisamment explicites pour permettre une délégation répétable. Les étapes de configuration cachées restent des points de défaillance cachés, quelle que soit la capacité de raisonnement de l’agent.

Cela crée un bénéfice secondaire pour l’intégration des humains. Les équipes qui documentent les environnements d’exécution, les services et les commandes de validation pour un agent rendent également le projet plus facile à comprendre pour les nouveaux ingénieurs.

Une base de connaissances d’ingénierie consultable peut compléter ce processus. L’environnement fournit le contexte d’exécution, tandis qu’une documentation maintenue explique l’architecture, les décisions et les contraintes opérationnelles.

Le véritable gain de productivité dépendra donc de bien plus que de machines virtuelles plus rapides. Il dépendra de la capacité des équipes à transformer des connaissances locales informelles en configurations réutilisables par d’autres développeurs et agents.

OpenAI Codex face à Claude : la continuité du workflow devient déterminante

L’avantage concurrentiel se déplace de la qualité de génération de code vers la continuité entre les tâches, les environnements et les interfaces de révision.

OpenAI n’arrive pas sur un terrain vide. Google Jules, l’agent cloud GitHub Copilot et Claude Code sur le web considèrent déjà le codage comme un travail pouvant se poursuivre sans supervision constante.

Google a présenté Jules comme un agent de codage asynchrone qui se connecte aux dépôts et opère dans un environnement cloud sécurisé. Son positionnement initial mettait l’accent sur l’attribution du travail, la possibilité de quitter la session et le retour ultérieur pour examiner les changements.

Le lancement de Jules décrivait un système qui lit une base de code, crée un plan et travaille de manière asynchrone. Cela a établi la délégation à distance comme une catégorie concurrentielle, plutôt que comme une idée propre à OpenAI.

GitHub occupe une position particulièrement forte, car de nombreuses tâches de développement commencent déjà dans les tickets et les pull requests. Son agent cloud peut explorer un dépôt, modifier une branche et exécuter des vérifications automatisées.

Le modèle d’agent cloud utilise un environnement de développement éphémère propulsé par GitHub Actions. Cela donne à Copilot un chemin direct entre l’attribution d’un ticket et une pull request examinée.

Anthropic aborde le même problème avec Claude Code. Son produit web permet aux utilisateurs de choisir un dépôt GitHub, de soumettre une tâche et de s’absenter pendant que le travail se poursuit à distance.

Chaque tâche web de Claude Code reçoit une machine virtuelle isolée. Le système peut également exécuter plusieurs tâches en parallèle et créer des pull requests une fois le travail terminé.

Le workflow de tâche distante met en avant un compromis familier. Les tâches web favorisent les affectations bien définies, tandis que les sessions dans un terminal ou un éditeur offrent un contrôle plus étroit pendant un travail ambigu.

Ce compromis est au cœur des comparaisons entre OpenAI Codex et Claude. La qualité des modèles compte, mais les utilisateurs remarquent aussi la quantité de contexte qui survit lorsqu’ils passent entre les interfaces locales, web et mobiles.

La réponse d’OpenAI consiste à faire de l’environnement réutilisable un point de départ durable. Au lieu de demander aux développeurs de configurer chaque tâche distante indépendamment, Codex peut lancer de nouveaux travaux depuis une configuration de projet publiée.

Cela ne rend pas automatiquement Codex plus capable que Claude Code, Jules ou Copilot. Cela modifie l’endroit où OpenAI cherche à créer un effet de levier.

Un environnement réutilisable peut réduire les préparatifs répétés pour de nombreuses tâches. Un environnement éphémère peut réduire les états obsolètes et rendre chaque exécution plus facile à comprendre.

Aucune de ces approches ne l’emporte dans toutes les situations. Les projets stables nécessitant une configuration coûteuse bénéficient de la réutilisation, tandis que les projets qui évoluent rapidement ou sont sensibles en matière de sécurité peuvent préférer une reconstruction plus fréquente.

Les fournisseurs contrôlent également différents points d’entrée dans le workflow. GitHub possède la surface des dépôts et des pull requests. Google peut relier Jules à sa plateforme de développement plus large, tandis qu’Anthropic associe la délégation web à l’expérience terminal de Claude Code.

OpenAI construit autour de la continuité entre ses propres interfaces Codex. Une tâche peut commencer sur un ordinateur de bureau, se poursuivre dans une infrastructure gérée par OpenAI et recevoir des instructions de suivi depuis un autre appareil.

Cela fait du principal affrontement quelque chose de plus vaste qu’OpenAI Codex face à Claude. Il s’agit d’une confrontation entre une assistance centrée sur l’ordinateur portable et une délégation centrée sur le cloud.

Dans le premier modèle, l’agent aide au sein de la session active d’un développeur. Dans le second, le développeur supervise un travail qui dispose de son propre environnement d’exécution et de son propre calendrier.

La mise à jour rapproche Codex du second modèle sans abandonner les outils locaux. OpenAI propose toujours des flux de travail via le terminal, l’éditeur, le bureau et le web, mais le cloud devient une destination partagée pour les tâches de longue durée.

Le plan de contrôle s’éloigne de l’ordinateur portable

L’accès multi-appareils transforme l’ordinateur du développeur, d’un centre d’exécution, en l’un de plusieurs points de supervision.

Un agent centré sur l’ordinateur portable suppose que le développeur, le dépôt, les outils et le processus en cours restent physiquement connectés. Cette hypothèse fonctionne pour le débogage interactif, mais limite les missions plus longues.

Codex Cloud retire l’ordinateur local du chemin d’exécution critique. OpenAI héberge la machine virtuelle, et le compte authentifié devient le fil reliant les différentes interfaces.

Un développeur peut préparer un environnement sur le web ou dans l’application de bureau, lancer une tâche, puis fermer son ordinateur. La même tâche peut ensuite être rouverte depuis un autre ordinateur ou un téléphone.

Ce flux modifie le rythme du développement agentique. Au lieu de surveiller chaque commande, le développeur peut déléguer une tâche délimitée et revenir lorsque l’agent atteint un état révisable.

L’accès mobile est particulièrement révélateur. Peu de développeurs souhaitent examiner un gros diff ou diagnostiquer un test en échec sur un petit écran.

Ils peuvent toutefois vouloir répondre à une question, réorienter une approche ou vérifier si une tâche est bloquée. Une interface mobile peut prendre en charge ces décisions sans prétendre remplacer une station de développement complète.

La distinction entre une nouvelle tâche et une tâche existante devient ici importante. Ouvrir la même tâche préserve ses fichiers sauvegardés et ses outils installés, tandis qu’en démarrer une autre crée un travail distinct.

Cette conception autorise des missions parallèles sans fusionner leurs répertoires de travail. Elle fait également de l’identité de la tâche un élément central de l’expérience produit.

Les environnements cloud vont au-delà des interfaces Codex directes. OpenAI indique que les espaces de travail Enterprise éligibles peuvent déléguer des tâches de dépôt via Slack ou Microsoft Teams.

Le système utilise le contexte de la conversation pour choisir un environnement accessible au compte à l’origine de la demande. Les travaux de suivi doivent provenir du même compte connecté pour poursuivre la tâche initiale.

Cette exigence limite les reprises accidentelles par d’autres utilisateurs. Elle montre aussi que l’autorisation devient plus complexe lorsque le travail de programmation commence dans des canaux de communication partagés.

Le développeur gère donc plusieurs couches simultanément. L’une définit l’environnement réutilisable, une autre conserve l’état propre à la tâche, et une troisième détermine quel compte peut poursuivre le travail.

Lorsque ces couches sont claires, le travail multi-appareils peut sembler cohérent. Lorsqu’elles ne le sont pas, les utilisateurs peuvent facilement lancer une nouvelle tâche et se demander pourquoi les modifications ou outils précédents sont absents.

La conception d’OpenAI influence également les opérations d’équipe. Un environnement partagé peut donner aux collègues accès à la même configuration préparée sans leur accorder l’accès aux fichiers de tâche d’une autre personne.

Les identifiants personnels restent séparés de la configuration partagée. Les membres de l’équipe peuvent fournir leurs propres valeurs via un coffre-fort personnel lorsqu’un environnement les demande.

C’est une frontière raisonnable, mais les administrateurs ont toujours besoin de politiques relatives à l’accès aux dépôts, aux destinations réseau et à la propriété des environnements. La réutilisation augmente la valeur d’une configuration correcte comme l’impact d’une configuration incorrecte.

L’ordinateur portable n’a pas disparu du développement. Les sessions locales restent mieux adaptées au travail exploratoire, au débogage immédiat et aux tâches dépendant de ressources locales privées.

Le changement est que l’ordinateur portable n’est plus le seul endroit où un travail de programmation significatif peut persister. Il devient une console au sein d’un flux de travail distribué.

Pour les développeurs, cela peut transformer les périodes d’inactivité en cycles de révision. Une tâche peut s’exécuter pendant un trajet, une réunion ou le temps passé entre deux ordinateurs.

Pour les responsables, cela crée un autre problème de coordination. Les équipes doivent décider quelles tâches sont suffisamment délimitées pour être déléguées et lesquelles exigent encore une interaction humaine étroite.

Le principal bénéfice ne viendra pas de l’envoi de chaque ticket dans le cloud. Il viendra du choix de missions dont les exigences, les tests et les conditions d’acceptation sont suffisamment clairs pour une exécution asynchrone.

La sécurité et l’état sont les véritables contraintes

L’environnement cloud réduit les frictions de configuration en préservant davantage d’état, ce qui rend le contrôle des accès et l’hygiène des environnements plus déterminants.

Un agent de programmation a besoin de plus que du code source pour effectuer un travail utile. Il peut nécessiter des registres de paquets, des services de test, des API de déploiement, de la documentation interne ou des ressources cloud.

Chaque connexion supplémentaire étend l’autorité du système. Elle crée également une nouvelle voie par laquelle du contenu non fiable ou des commandes générées par l’agent peuvent causer des dommages.

OpenAI permet aux propriétaires d’environnements de configurer des variables d’environnement et des secrets réseau. Les programmes reçoivent directement les variables ordinaires, tandis qu’un proxy remplace les secrets réseau pour les destinations HTTPS approuvées.

Cette distinction peut empêcher qu’un identifiant brut ne se retrouve dans les fichiers et processus locaux de la tâche. Elle ne dispense pas de restreindre les endroits où cet identifiant peut être utilisé.

L’accès à Internet constitue une autre frontière importante. OpenAI indique que l’accès Internet de l’agent est bloqué par défaut pendant la phase de travail, bien que les scripts de configuration puissent accéder à Internet.

Les administrateurs ou propriétaires d’environnements peuvent activer cet accès et le restreindre aux gestionnaires de paquets ou à certains domaines. Un accès plus large permet davantage de tâches, mais augmente aussi l’exposition.

Les recommandations réseau de l’entreprise identifient l’injection de prompt, l’exfiltration de secrets, les téléchargements malveillants et les problèmes de licence comme des risques pertinents. Il s’agit de préoccupations opérationnelles, non de cas limites théoriques.

Un ticket de dépôt peut contenir des instructions non fiables. Un document de dépendance peut tenter de réorienter l’agent. Un paquet compromis peut exploiter l’accès réseau de l’environnement.

Les configurations réutilisables accroissent la commodité parce qu’elles préservent une configuration testée. Elles peuvent également conserver des dépendances obsolètes, des permissions excessives ou des hypothèses qui ne correspondent plus au dépôt.

Les équipes devraient traiter les modifications d’environnement comme des changements d’infrastructure. Elles ont besoin de revue, de responsables, de tests et d’un historique clair expliquant pourquoi l’accès a été accordé.

L’état sauvegardé des tâches soulève une autre question de gouvernance. OpenAI indique que l’état de la machine virtuelle d’une tâche est récupérable jusqu’à sept jours après le démarrage ou la reprise d’un tour par l’utilisateur.

Cette fenêtre prend en charge le travail de suivi entre appareils. Elle implique également que les équipes doivent comprendre quels fichiers non validés et artefacts générés restent attachés à une tâche.

Les ressources par défaut des machines virtuelles varient selon le type de compte. OpenAI documente deux processeurs virtuels, 8 Gio de mémoire et 8 Gio de disque pour certains utilisateurs.

D’autres types de comptes pris en charge reçoivent par défaut quatre processeurs virtuels, 16 Gio de mémoire et 32 Gio de disque. Les clients Enterprise peuvent demander des spécifications plus importantes ou personnalisées.

Ces limites façonnent ce que les développeurs peuvent déléguer. Une suite de tests classique peut s’exécuter confortablement, tandis qu’une compilation volumineuse, un émulateur ou une charge de travail riche en données peut dépasser l’environnement standard.

Les lacunes fonctionnelles actuelles restreignent aussi les cas d’usage. OpenAI indique que les environnements cloud ne prennent pas encore en charge l’utilisation de l’ordinateur ou du navigateur.

La documentation liste également GitLab et GitHub Enterprise Server auto-hébergé comme non pris en charge dans l’expérience actuelle des environnements cloud. OpenAI place ces capacités sur sa feuille de route.

Ces limitations empêchent le produit de reproduire chaque flux de travail local. Une tâche nécessitant des tests pilotés par navigateur, un hébergement de code source non pris en charge ou une compétence locale personnelle exige encore un autre chemin d’exécution.

Il existe aussi un risque plus subtil : la confiance peut augmenter plus vite que la fiabilité. Un environnement préparé permet de démarrer une tâche sans accroc, mais une configuration réussie ne garantit pas une implémentation correcte.

Les développeurs doivent toujours examiner le diff, évaluer la couverture de tests et vérifier le comportement. Le résumé de l’agent doit guider la revue, non la remplacer.

Les environnements cloud OpenAI Codex déplacent donc la responsabilité au lieu de la supprimer. Les développeurs passent moins de temps à reconstruire l’espace de travail et davantage à définir les permissions, la validation et les critères d’acceptation.

Cela peut constituer un compromis productif. Il ne fonctionne que lorsque les équipes considèrent l’agent cloud comme un exécutant au sein d’une infrastructure contrôlée, et non comme un développeur infaillible.

Trois signaux détermineront si le modèle s’impose

L’adoption dépendra de la réutilisation des configurations, des réactions concurrentielles et de preuves que la supervision multi-appareils améliore le travail achevé.

Le premier signal est la fréquence à laquelle les développeurs réutilisent un environnement publié. La création d’environnement paraît utile lorsqu’elle est observée dans une démonstration produit, mais l’usage récurrent constitue le test le plus solide.

Si les équipes lancent à répétition des tâches depuis la même configuration, OpenAI a réduit une véritable source de friction. Si les utilisateurs continuent de reconstruire ou de contourner les environnements, l’abstraction est trop fragile.

Il faudra observer comment OpenAI améliore le versionnage, le débogage et la propriété des environnements. Une visibilité claire sur la configuration utilisée par une tâche sera importante à mesure que les projets et les équipes grandissent.

Le deuxième signal est la manière dont les concurrents répondent à l’état de projet réutilisable. Claude Code, Jules et GitHub Copilot prennent déjà en charge le travail cloud asynchrone ; l’exécution distante seule offre donc une différenciation limitée.

Une réponse plus forte impliquerait une configuration durable et partageable entre les tâches et les appareils. Cela confirmerait que l’environnement préparé est devenu une nouvelle couche concurrentielle.

Une réponse plus faible suggérerait que les développeurs préfèrent que les dépôts assurent la configuration via des fichiers de configuration standards. Dans ce cas, la gestion d’environnement propre à un fournisseur pourrait rester une commodité plutôt qu’un avantage de plateforme.

Le troisième signal est de savoir si le suivi mobile et multi-appareils modifie les taux d’achèvement. Lancer une tâche depuis un téléphone est intéressant, mais achever un travail utile est le résultat qui compte.

OpenAI doit montrer que les développeurs peuvent résoudre les blocages, réorienter les tâches et parvenir à des résultats révisables sans revenir à la machine d’origine. Des notifications fiables et des rapports d’avancement concis influenceront cette expérience.

Ces signaux révéleront également les limites de la programmation asynchrone. Les tâches dotées de tests clairs et d’un périmètre étroit devraient en bénéficier les premières.

Le travail d’architecture ambigu restera plus difficile. Il exige des jugements répétés, un contexte plus riche et une interaction plus étroite qu’une tâche en arrière-plan ne peut supposer de manière fiable.

La mise à jour de septembre d’OpenAI fait un pari précis : la prochaine unité de productivité des développeurs n’est pas une autre suggestion intégrée. C’est un espace préparé et persistant où un agent peut travailler de manière indépendante.

Ce pari pousse chaque fournisseur d’agents de programmation à résoudre les mêmes questions opérationnelles. Ils doivent gérer le contexte, les identifiants, l’état, la revue et les déplacements entre appareils.

Pour les développeurs, l’action immédiate est simple. Identifiez un dépôt dont la configuration est coûteuse et une tâche délimitée disposant de tests solides.

Préparez l’environnement, déléguez la tâche, puis mesurez l’ensemble du parcours, de la demande à la modification revue. Incluez les échecs de configuration, les corrections et le temps de revue.

Si les environnements cloud OpenAI Codex raccourcissent ce cycle complet, la mise à jour modifie plus que l’endroit où le code s’exécute. Elle modifie la manière dont les développeurs planifient, supervisent et reprennent le travail logiciel.

S’ils ne font que déplacer les frictions existantes vers une machine hébergée, les outils locaux resteront le centre le plus fiable. La question décisive est de savoir si votre prochaine tâche revient prête à être revue, et non si elle a continué à s’exécuter toute la nuit.