Aller au contenu principal
Ce projet est en phase bêta. Tu as trouvé un bug ? Ouvrir un ticket GitHub. Une question ou une idée ? Pose ta question dans Discussions — tes retours sont les bienvenus !
Quelle est la qualité de la traduction sur cette page ?

Introduction aux workflows gérés

Disponibilité selon le plan

Les Qiskit Functions et les workflows gérés sont des fonctionnalités bêta disponibles uniquement pour les utilisateurs des plans Premium, Flex et On-Prem (via l'API d'IBM Quantum® Platform).

Les workflows gérés exécutent ton code Python personnalisé sur du calcul classique que IBM Quantum Platform gère pour toi. Utilise les workflows gérés pour exécuter des workflows hybrides quantiques-classiques, des diagonalisations à grande échelle et des tâches parallèles de longue durée sans gérer d'infrastructure de calcul ni de stockage.

Quand utiliser un workflow géré​

Utilise un workflow géré lorsqu'aucune Catalog Function prête à l'emploi ne couvre ta tâche, ou lorsque tu veux empaqueter ta propre méthode sous forme de fonction réutilisable. Les workflows gérés conviennent bien lorsque tu veux faire ce qui suit :

  • Exécuter de longs jobs dans le cloud. Un workflow géré continue de s'exécuter lorsque tu fermes ton ordinateur portable, et tu peux te reconnecter au job plus tard.

  • Utiliser des nœuds à grande mémoire et des nœuds GPU. Choisis les ressources de mémoire, de CPU et de GPU dont la charge de travail a besoin.

  • Exécuter des tâches en parallèle. Démarre de nombreux jobs à nœud unique en même temps.

Tu fournis le code du workflow, ses dépendances et les tailles de calcul qu'il prend en charge. Les workflows gérés exécutent le workflow sur du calcul géré par IBM® dans un environnement préconstruit avec tes paquets installés, et fournissent un stockage cloud pour les fichiers que le workflow lit et écrit.

Comment fonctionnent les workflows gérés​

Tu téléverses un workflow une seule fois et tu exécutes autant de jobs que nécessaire. Chaque job fonctionne de la manière suivante :

  • Le job démarre dans un nouvel environnement avec un disque local vide. Les workflows gérés arrêtent l'environnement après la fin du job.

  • Le job s'exécute sur l'une des tailles de calcul que tu définis lorsque tu téléverses le workflow. Tu peux choisir une taille différente pour chaque exécution.

  • Le job peut lire et écrire dans le stockage de fichiers du workflow. Les fichiers du stockage de fichiers subsistent après la fin du job.

Comme chaque job démarre avec un disque local vide, un job ultérieur ne peut trouver que les fichiers qu'un job précédent a enregistrés dans le stockage de fichiers.

Cycle de vie d'une exécution​

Chaque job s'exécute de manière asynchrone pendant 24 heures au maximum. Tu peux avoir jusqu'à 50 jobs actifs en même temps si ton instance dispose d'une allocation suffisante.

From your Python session, you call upload() one time to upload the workflow's code, packages, and compute profiles. No job exists yet. Each call to run(args) creates a job that moves through these stages: Queue, where it waits for allocation with status QUEUED; Start, where the managed workflow creates the environment with status INITIALIZING; Running, where your code can optionally set stages with update_status(): Mapping (RUNNING: MAPPING), Optimizing (RUNNING: OPTIMIZING_FOR_HARDWARE), Waiting for QPU (RUNNING: WAITING_FOR_QPU), Executing QPU (RUNNING: EXECUTING_QPU), and Post-processing (RUNNING: POST_PROCESSING); and Result, where the environment shuts down with status DONE, ERROR, or CANCELED. While running, the job reads and writes workflow file storage, which exists outside the job, is shared by all runs, and persists before and after each job. From your session, you can read status() from Queue onward, logs() from Running onward, and result() after the job reaches Result. All three remain available after the job ends.

Le tableau suivant décrit chaque étape du diagramme et le statut du job que tu vois pendant cette étape :

ÉtapeCe qui se passeStatut du job
TéléversementTu téléverses le code du workflow, ses dépendances et ses tailles. Le workflow rejette un téléversement invalide avant l'exécution de tout job.Aucun (pas encore de job)
File d'attenteTu appelles run(). Le workflow vérifie si ton instance dispose d'une allocation suffisante et planifie le job lorsque du calcul est disponible.QUEUED
DémarrageLe workflow crée un environnement avec le profil de calcul que tu as sélectionné.INITIALIZING
ExécutionLe point d'entrée de ton workflow s'exécute. Le point d'entrée peut signaler sa progression avec update_status(), et tu peux lire ses logs avec logs() pendant l'exécution.RUNNING, ou une étape que tu définis, comme RUNNING: WAITING_FOR_QPU
RésultatLe job se termine, et le workflow arrête son environnement tout en conservant le résultat et les logs.DONE, ERROR ou CANCELED

À quoi un job en cours d'exécution peut accéder​

Chaque job s'exécute dans un environnement isolé. Le diagramme et le tableau suivants montrent les ressources qu'un job en cours d'exécution peut utiliser.

You call run() with arguments from your Python session and receive status, logs, and the result. Inside the managed workflow, each run executes in an isolated job environment with access to its compute (CPU, RAM, and optionally GPU), your code and packages, and its arguments. The job produces outputs with save_result(), logs, and update_status(), and submits QPU jobs that run on your instance. File storage and your instance, which provides access and cost management, are shared across all managed workflow jobs and persist after the job ends. The job has no internet access.

RessourceCe que le job peut utiliser
CalculLes CPU, la mémoire et les GPU du profil de calcul que tu as sélectionné pour le job.
Code et paquetsLes fichiers que tu as téléversés avec le workflow, et les paquets pris en charge qui sont installés dans l'environnement.
ArgumentsLes arguments que tu as passés à run(). Lis-les avec get_arguments().
Accès QPULes identifiants et l'instance que tu as utilisés pour appeler run(). Les jobs QPU que le workflow soumet s'exécutent sur ton instance et comptent dans ton utilisation.
SortiesUn résultat que le job enregistre avec save_result(), les logs que le job affiche et les mises à jour de statut que le job définit avec update_status().
Stockage de fichiersFichiers que toutes tes exécutions du workflow partagent. Les fichiers restent dans le stockage après la fin du job.
InternetAucun accès. Un job ne peut pas établir de connexions sortantes. Déclare les paquets lorsque tu téléverses le workflow, et fournis les données sous forme d'arguments ou de fichiers.

Sécurité et isolation​

Les workflows gérés isolent chaque job des autres jobs et limitent les privilèges du code qui s'y exécute. Les limites d'accès du tableau précédent font partie de cette isolation. Les workflows gérés appliquent aussi les protections suivantes :

  • Isolation des jobs. Aucun autre job ne s'exécute dans l'environnement de ton job. Cela inclut les jobs d'autres utilisateurs et tes propres jobs qui s'exécutent en même temps.

  • Résultats, logs et stockage. Seul l'utilisateur qui a exécuté un job peut lire ses résultats et ses logs.

  • Identifiants. Les workflows gérés chiffrent les identifiants qu'un job utilise, y compris ton jeton d'API, lorsqu'ils les stockent. Le code de ton workflow peut lire ces identifiants pendant l'exécution du job.

  • Privilèges. Les workflows gérés retirent les privilèges de niveau administrateur de l'environnement avant le démarrage de ton point d'entrée.

Comparaison avec le HPC sur site​

Les workflows gérés diffèrent d'un cluster HPC sur site par la façon dont tu obtiens du temps de calcul, configures les logiciels et soumets les jobs. Le tableau suivant compare les tâches courantes.

TâcheCluster HPC sur siteWorkflows gérés
Obtenir du temps de calculDemander une allocation ou une réservation à l'administrateur du cluster.Utiliser l'allocation de ton instance IBM Quantum. Le workflow met chaque job en file d'attente lorsque tu appelles run().
Accéder au systèmeSe connecter à un nœud de connexion avec SSH.Utiliser le client Python sur ton ordinateur local. Les workflows gérés ne fournissent pas de nœud de connexion.
Installer des logicielsCompiler des logiciels, charger des modules ou demander à un administrateur d'installer des paquets.Utiliser les paquets pris en charge qui sont installés dans chaque environnement, ou téléverser des wheels pour d'autres paquets.
Soumettre un jobÉcrire un script batch et le soumettre à l'ordonnanceur.Appeler run() avec les arguments du job.
Demander des ressourcesDemander des nœuds, des CPU, de la mémoire et des GPU.Sélectionner l'une des tailles de calcul définies pour le workflow. Chaque job s'exécute sur un seul nœud.
Exécuter un balayage de paramètresSoumettre un tableau de jobs.Appeler run() une fois pour chaque ensemble d'arguments.
Stocker des fichiers partagésÉcrire dans un système de fichiers scratch partagé.Écrire dans le stockage de fichiers du workflow.
Limiter la durée d'exécutionDéfinir une limite de temps réel.Le workflow annule un job après 24 heures.
Placer des points de contrôle dans les longs jobsÉcrire des points de contrôle dans le stockage scratch.Enregistrer les résultats intermédiaires dans le stockage de fichiers.
Relancer un job échouéSoumettre à nouveau le job.Appeler run() à nouveau. Le workflow ne réessaie pas automatiquement les jobs échoués.
Surveiller les jobsConsulter la file d'attente et les fichiers de logs depuis le nœud de connexion.Consulter le statut, les logs et le résultat de chaque job depuis ta session Python locale.

Prochaines étapes​

Recommandations
Source : Documentation IBM Quantum — mis à jour le 6 nov. 2026
Version anglaise sur doQumentation — mise à jour le 6 nov. 2026
Problème avec le site ou la traduction ?Problème de contenu ? Modifier sur IBM Quantum docs