IBM étend encore Qiskit au-delà de Python avec la sortie du SDK v2.6

IBM a publié Qiskit SDK v2.6, une mise à jour logicielle centrée sur l’interface C bas niveau du projet plutôt que sur sa couche Python, plus connue. Selon le résumé de publication d’IBM du 22 octobre, la mise à jour ajoute un framework de gestionnaire de passes à l’API C, intègre la sérialisation de circuits QPY aux workflows en langage compilé et permet aux développeurs de définir des opérations quantiques personnalisées directement depuis le C. Dans leur ensemble, ces évolutions prolongent les efforts d’IBM pour rendre une plus grande partie de Qiskit utilisable sans environnement d’exécution Python.

Ce qui a été annoncé

La version v2.6 étend l’API C de Qiskit, qu’IBM présente comme une interface bas niveau vers le modèle de données central de Qiskit, fondé sur Rust, pour un usage depuis des langages compilés. IBM indique que cette interface est pensée à la fois pour un usage autonome sans Python et pour créer des extensions Python plus performantes interagissant directement avec les objets Rust de Qiskit.

Dans Qiskit v2.6, IBM a ajouté à cette API C un framework générique de gestionnaire de passes. Les nouveaux composants comprennent QkPassManager, QkPassVtable et QkIrHandle, qui permettent ensemble aux développeurs de créer des passes de compilation et de les chaîner dans des pipelines vérifiés par type à travers plusieurs représentations intermédiaires.

Recevez la newsletter de DesignQuantum

Actualités et articles de fond gratuits sur l’informatique quantique, chaque affirmation étant liée à sa source. Quotidienne, hebdomadaire ou mensuelle, au choix.

Website

Adresse e-mail FréquenceQuotidienneHebdomadaireMensuelle LangueEnglishEspañol简体中文हिन्दीالعربيةPortuguês (Brasil)FrançaisDeutsch日本語Русский한국어Bahasa IndonesiaTürkçeItalianoTiếng ViệtPolskiNederlandsไทยفارسیУкраїнськаবাংলাاردوKiswahiliBahasa Melayuעברית M’abonner gratuitement

Gratuit. Désabonnement en un clic à tout moment. Politique de confidentialité

La publication expose également dans l’API C les fonctions de sérialisation QPY, ce qui permet à des programmes écrits dans des langages comme le C, le C++ et Julia d’écrire et de lire le format binaire de circuits de Qiskit sans passer par Python. En outre, les développeurs peuvent désormais définir des opérations personnalisées via une interface C de type vtable, y compris des opérations natives au matériel, selon IBM.

Les détails techniques

IBM indique que le nouveau framework de gestionnaire de passes peut valider un pipeline de compilation avant son exécution en vérifiant les représentations d’entrée et de sortie déclarées pour chaque passe. Les représentations intégrées comprennent QkCircuit et QkDag, tandis que des RI définies par l’utilisateur peuvent aussi être décrites via QkIrHandle.

C’est important, car le travail de compilation de Qiskit s’organise de plus en plus autour de l’abaissement des programmes à travers plusieurs représentations, un schéma pertinent à la fois pour les flux actuels de transpilation et pour les futures chaînes d’outils tolérantes aux fautes.

Côté sérialisation, Qiskit 2.6 fait du format QPY v18 le choix par défaut. IBM affirme que cette version réduit la taille des circuits sérialisés grâce à un encodage plus compact des registres quantiques et classiques. Les circuits produits via l’API C restent compatibles avec le module Python qiskit.qpy, selon l’entreprise.

La publication maintient la version minimale de Python prise en charge à 3.10, tandis que les compilations depuis le code source exigent désormais Rust 1.89. La page de feuille de route d’IBM indique également que Qiskit 2.6.0 a été publié le 16 octobre 2026 et que les corrections de bugs seront livrées via des patch releases ou la prochaine version mineure.

Pourquoi c’est important

Pour la plupart des utilisateurs de Qiskit, Python reste le principal point d’entrée. Mais IBM construit clairement aussi en vue d’un autre modèle de déploiement : un accès, depuis des langages compilés, à la même pile centrale de compilation et d’exécution.

Cette évolution est pertinente pour les environnements de calcul haute performance, où Python peut constituer une contrainte d’empaquetage, d’exécution ou d’intégration. La documentation d’IBM indique que l’API C est conçue pour fournir une ABI définie vers le modèle de données interne en Rust, et le blog de l’entreprise présente la v2.6 comme une étape supplémentaire vers l’usage de Qiskit dans des environnements où Python n’est pas installé.

Elle signale aussi une transition architecturale plus large. La feuille de route de Qiskit montre qu’IBM travaille vers une stabilité formelle de l’ABI et de l’API pour l’interface C dans la v2.7, ainsi que vers une nouvelle RI de middle-end pour la compilation tolérante aux fautes. Pour la v2.8, la feuille de route mentionne BackendV3, qui y est décrit comme une interface backend native Rust exposée à Python et au C.

Ce qu’il faut surveiller

La question immédiate est celle de la stabilité. La documentation actuelle de l’API C d’IBM indique que l’interface doit encore être considérée comme expérimentale et qu’elle peut changer entre les versions mineures. Cette réserve est importante pour les équipes logicielles qui envisagent une intégration poussée.

La prochaine étape est donc Qiskit 2.7. Selon la feuille de route GitHub, cette version devrait définir des garanties de stabilité pour l’API C et étendre davantage les fonctionnalités du compilateur. Si IBM concrétise cela, la trajectoire non-Python de Qiskit commencera moins à ressembler à un projet de plomberie interne qu’à une interface de production pour des piles logicielles quantiques compilées.