Introduction
Les logiciels quantiques couvrent les langages de programmation, les compilateurs, l'optimisation des circuits, l'atténuation des erreurs, les systèmes de contrôle, les simulateurs, l'orchestration des flux de travail, les bibliothèques d'applications, l'estimation des ressources et les solutions de domaine. Certains produits se situent à proximité d’un processeur quantique. D'autres coordonnent le calcul quantique et classique, gèrent des expériences ou regroupent des méthodes scientifiques pour la chimie, la finance, l'optimisation et l'apprentissage automatique. Le périmètre de transaction peut donc contenir du code, des données, des brevets, des secrets commerciaux, des employés, des contrats clients, des relations cloud et des accès futurs au matériel.
La question centrale de l'acheteur est de savoir si la cible possède une capacité durable ou une implémentation temporaire adaptée à un appareil particulier. Un circuit qui s'exécute sur deux plates-formes peut produire une précision, une profondeur, un coût et une latence différents. Un compilateur peut réduire les portes sur une topologie tout en augmentant la surcharge de routage sur une autre. Une application peut s'appuyer sur l'accès par impulsions exclusif d'un fournisseur, sur un service d'atténuation des erreurs ou sur la priorité de file d'attente. Un contrat client peut financer la recherche plutôt qu'un produit reproductible.
L'évaluation devient difficile lorsque la portabilité est traitée comme un attribut oui ou non. Le logiciel peut être portable au niveau source et dépendant au niveau des performances. Il peut être compilé en une représentation commune tout en nécessitant un abaissement spécifique à la cible. Il peut reproduire un résultat mathématique tout en perdant la rapidité, le coût ou la précision qui étayaient l’affirmation commerciale. Il peut fonctionner sur du matériel alternatif tandis que la relation client reste liée à un fournisseur privilégié.
Cet article remplace l'affirmation générale d'indépendance matérielle par une hiérarchie de preuves. Il se demande ce qui bouge, ce qui doit être reconstruit, ce qui fonctionne, qui paie et quels droits transfèrent. Le résultat est un cadre de transaction pour les équipes de développement d’entreprise, les investisseurs, les fondateurs et les conseillers évaluant les acquisitions, les combinaisons et les investissements stratégiques de logiciels quantiques.
1 Définir la thèse d'acquisition
Le comité des transactions doit indiquer pourquoi la propriété est requise. Un acheteur peut rechercher un portefeuille d'algorithmes, un compilateur ou une couche de contrôle, une équipe d'application, un accès client, des données propriétaires, des brevets, une communauté de développeurs ou un moyen d'intégrer du matériel et des logiciels. Chaque thèse nécessite une diligence différente et produit un pont de valorisation différent.
Un acheteur de matériel peut apprécier les logiciels car ils améliorent l'utilisation, exposent les capacités de l'appareil et attirent des charges de travail. Un acheteur de cloud ou de plateforme peut valoriser l'abstraction, l'orchestration et la distribution. Un acheteur industriel peut apprécier un workflow de domaine et les scientifiques qui le comprennent. Un investisseur financier peut valoriser l’optionnalité chez plusieurs fournisseurs de matériel. Le comité doit identifier les revenus, les coûts, le temps ou la dépendance stratégique que l'acquisition modifie.
La thèse doit également énoncer le contrefactuel. Les alternatives peuvent inclure l'octroi de licences, le partenariat, la construction interne, l'adoption de l'open source, l'acquisition ou l'attente. Le temps de remplacement et le risque d’exécution comptent souvent plus que les dépenses de développement historiques. Une prime d’acquisition est difficile à justifier lorsqu’une alternative crédible atteint le même résultat client avant que le matériel quantique ne devienne commercialement pertinent.
Le document du conseil d'administration doit préciser la date d'évaluation, la sécurité, la contrepartie, le financement supposé et le budget d'intégration. Il doit identifier quelle valeur est présente à la clôture et laquelle dépend d'étapes techniques, client ou matérielles. Cette séparation permet au prix et à la protection de suivre les preuves.
2 Décomposer l'indépendance matérielle
La portabilité de la source signifie que le code ou un algorithme de haut niveau peut être déplacé ou traduit. La portabilité sémantique signifie que l'opération mathématique envisagée reste équivalente. La portabilité de la compilation signifie que le programme peut être réduit à une représentation intermédiaire acceptée et à un jeu d'instructions cible. La portabilité exécutable signifie que le flux de travail complet s'exécute sur une cible dans des conditions prises en charge.
La portabilité des performances améliore la qualité de la solution, l'utilisation des ressources, la latence, le débit et le coût. La portabilité commerciale demande si le client accepte le résultat, si le modèle de support reste viable et si les aspects économiques survivent. Ces couches doivent être testées séparément. Passer une couche antérieure n’établit pas la suivante.
Une représentation intermédiaire peut réduire le couplage langage et compilateur. Microsoft décrit la représentation intermédiaire quantique comme étant indépendante du langage et du matériel, utilisant l'infrastructure LLVM comme interface commune. L’environnement cible détermine toujours les portes disponibles, le flux de contrôle, les services de mesure, de synchronisation et d’exécution. Les profils cibles Azure Quantum documentent différentes fonctionnalités de branchement conditionnel, d’arithmétique et de boucles. L'acheteur doit tester le profil requis par chaque flux de travail précieux.
OpenQASM 3 fournit également un langage étendu pour les programmes quantiques et le contrôle classique en temps réel. Sa spécification permet aux implémentations de limiter le traitement d'exécution aux opérations que le matériel peut effectuer efficacement. Amazon Braket documente les déclarations, les opérations et les capacités des appareils prises en charge. L’existence d’une norme améliore donc l’interopérabilité tout en laissant des différences significatives de mise en œuvre.
3 Construire l'échelle de preuves de l'algorithme
Le premier niveau est une spécification mathématique avec un problème défini, des entrées, des sorties et un critère d'exactitude. La seconde est une simulation classique reproductible. La troisième est la compilation pour une cible nommée. Le quatrième est l'exécution sur du matériel avec des enregistrements complets de ressources et d'erreurs. Le cinquième concerne les performances répétées selon les dates, les appareils et les instances problématiques. Le sixième est un résultat accepté par le client.
Chaque niveau devrait avoir un ensemble de preuves gelées. Il doit contenir le code source, les dépendances, les fichiers d'environnement, les cas de test, les données, les graines, les paramètres du compilateur, les identifiants de cible, les enregistrements d'étalonnage, le temps d'attente, le temps d'exécution, les tirs, le post-traitement, les mesures de coût et de qualité des résultats. L'acquéreur doit être en mesure de reproduire le résultat revendiqué à partir d'un environnement propre.
La nouveauté algorithmique ne crée pas automatiquement de valeur commerciale. Une méthode peut être scientifiquement intéressante alors que les alternatives classiques restent plus rapides, moins chères ou plus précises. Une application intéressante doit définir la décision améliorée, la ligne de base pertinente et les conditions dans lesquelles le calcul quantique ou d’inspiration quantique change l’économie.
L'échelle doit identifier le niveau de preuve le plus élevé atteint pour chaque produit. Un portefeuille peut contenir des logiciels de diagnostic d'erreurs matures, des routines d'optimisation expérimentale et des recherches non financées. L’application d’un multiple de revenus aux trois masque la différence. L’évaluation doit répartir séparément la valeur obtenue et la valeur conditionnelle de l’option.
4 Mesurer la qualité du benchmark
Les benchmarks doivent répondre à une question de transaction. Les benchmarks orientés applications QED-C évaluent la fidélité des résultats, le temps d'exécution et la consommation de ressources selon les algorithmes et la taille des problèmes. Ils sont utiles car ils vont au-delà d’une seule métrique matérielle. L'acheteur doit tout de même vérifier si le benchmark représente les charges de travail des clients de la cible et si les choix d'implémentation privilégient une plateforme.
Le plan de référence doit inclure des instances retenues, des références classiques et des configurations cibles multiples. Il doit enregistrer le temps de compilation, la largeur et la profondeur du circuit, les opérations à deux qubits, les tirs, le temps d'attente, le temps d'exécution, le post-traitement classique, les tentatives et le coût total. La qualité de la solution doit être définie avant que les résultats ne soient connus.
Les versions du matériel et du compilateur sont importantes. Un résultat peut s'améliorer grâce à l'étalonnage, à la transpilation ou à l'atténuation des erreurs plutôt qu'à l'algorithme propriétaire de la cible. L'acheteur doit réexécuter une implémentation de base via la même pile et tester la contribution de la cible via l'ablation. La valeur propriétaire est prise en charge lorsque l’amélioration persiste après le contrôle de l’accès et de la configuration.
La gouvernance de référence devrait empêcher les rapports sélectifs. Toutes les instances tentées, les exclusions et les exécutions ayant échoué doivent être conservées. L'équipe de diligence doit comprendre le réglage des paramètres et savoir si les déploiements clients nécessitent une intervention spécialisée similaire. Un résultat qui dépend d'un réglage manuel dirigé par le fondateur peut représenter une valeur de services ou de talents plutôt qu'un produit logiciel évolutif.
5 Compilateur de cartes et dépendance à la représentation intermédiaire
La compilation quantique comprend la décomposition, le mappage, le routage, la planification, l'optimisation, la réduction des impulsions et l'intégration de l'exécution. Une application peut faire appel à une bibliothèque de haut niveau tandis que les performances génératrices de valeur résident dans des passes tierces ou dans des services de fournisseurs. L'acheteur doit retracer chaque transformation depuis la source jusqu'au travail exécuté.
Le graphe de dépendances doit identifier les langages, les bibliothèques, les représentations intermédiaires, les compilateurs, les plugins, les backends cibles, les simulateurs, les API cloud et les services classiques. Pour chaque composant, la diligence doit enregistrer la propriété, la licence, la version, la maintenance, les efforts de remplacement et l'importance opérationnelle. La disponibilité de l'open source réduit certains risques d'acquisition tout en créant des obligations de gouvernance et de compatibilité.
Les performances du compilateur doivent être testées par cible. Une passe qui réduit la profondeur sur un graphique de connectivité peut apporter des avantages limités ailleurs. Les circuits dynamiques, les mesures à mi-circuit, la réinitialisation, l'accès aux impulsions et les fonctionnalités d'atténuation des erreurs peuvent modifier l'algorithme disponible. Les profils cibles QIR et la documentation du fournisseur doivent être rapprochés des exigences réelles de la cible.
L'acquéreur doit reproduire une version propre sans informations d'identification du fondateur, fichiers locaux ou services non divulgués. Il doit régénérer les artefacts intermédiaires et exécuter un benchmark convenu. La reproductibilité de la construction prend en charge la transférabilité. Il n’établit pas en soi la liberté d’exploitation, l’échelle ou la valeur client.
6 Tester la portabilité selon les modalités matérielles
Les modalités matérielles diffèrent en termes de connectivité, d'opérations natives, de mesure, de réinitialisation, de cohérence, de durée de porte, de contrôle et d'économie de file d'attente. Les systèmes supraconducteurs, à ions piégés, à atomes neutres, photoniques et de recuit peuvent nécessiter différentes formulations ou choix de compilation. Une revendication de portabilité doit spécifier la classe de problème et la cible prises en charge.
La matrice de test doit inclure au moins une cible principale, une alternative crédible et un simulateur ou émulateur. La même charge de travail doit utiliser des données d’entrée et des critères d’acceptation définis. Les différences dans la qualité, la profondeur, la durée d’exécution, les tentatives et le coût des solutions doivent être mesurées. Lorsque l'algorithme change sensiblement en fonction de la cible, l'acheteur doit traiter chaque implémentation comme un produit géré distinct.
L’accès du fournisseur peut être un atout caché. Les files d'attente prioritaires, la capacité réservée, les informations d'étalonnage, l'assistance technique et les fonctionnalités non publiques peuvent prendre en charge des résultats que les clients ordinaires ne peuvent pas reproduire. Les contrats doivent être examinés pour l'affectation, le changement de contrôle, la tarification, les données et la continuité. La valorisation doit séparer le logiciel des accès privilégiés.
La portabilité peut également affaiblir la différenciation. Si une représentation standard permet aux concurrents de déplacer facilement des algorithmes équivalents, le fossé peut résider dans les données, l'optimisation, l'intégration des flux de travail ou les relations clients. Le rapport de diligence doit indiquer quelle couche reste propriétaire une fois le programme exprimé via des interfaces ouvertes.
7 Diligence propriété intellectuelle et open source
L'acheteur doit cartographier les brevets, les droits d'auteur, les secrets commerciaux, les droits sur les données, les licences et les accords de contributeur pour chaque produit. Les référentiels sources doivent afficher la paternité, l'historique des validations, les composants et les versions tiers. Les affectations des employés et des entrepreneurs doivent être terminées. Les travaux financés par l’université ou le gouvernement peuvent comporter des droits et des obligations supplémentaires.
Les logiciels open source peuvent accélérer leur adoption et créer une communauté de développeurs. Cela peut également permettre aux concurrents d’utiliser les capacités de base. L'acheteur doit comprendre quels référentiels sont ouverts, quels composants restent propriétaires et si un changement de licence est juridiquement et commercialement pratique. Les obligations de copyleft, d’attribution, de notification, de brevet et de redistribution doivent être examinées par un avocat qualifié.
Les données de formation, les données moléculaires, les ensembles de données clients et les corpus de référence peuvent être importants. La cible doit démontrer la provenance, le consentement, les droits d’utilisation contractuels, les droits de conservation et de transfert. Les données obtenues pour un projet spécifique peuvent ne pas être réutilisables après une acquisition. Les données synthétiques ou publiques peuvent être remplaçables et ne doivent pas recevoir de valeur de rareté non justifiée.
Les secrets commerciaux nécessitent des contrôles opérationnels. L'acheteur doit examiner l'accès, la documentation, le cryptage, la délocalisation et la concentration des connaissances. Une méthode connue d’un seul chercheur doit être valorisée avec un risque de rétention et de transfert. Les brevets doivent être associés au produit réel plutôt que comptés.
8 Séparer les revenus des produits du financement de la recherche
Les revenus des logiciels quantiques peuvent inclure les abonnements, les licences, les services professionnels, les récompenses gouvernementales, les collaborations de recherche, les paiements d'étape et l'utilisation du cloud. Ces catégories ont une répétabilité et des marges brutes différentes. L'acheteur doit rapprocher les contrats, les factures, l'acceptation et la trésorerie par client et par produit.
Les revenus récurrents devraient nécessiter une obligation continue et une base de renouvellement crédible. Un accord de recherche pluriannuel peut fournir des liquidités contractuelles tout en finançant des travaux sur mesure. Un projet pilote peut démontrer le budget et l'engagement sans prouver l'adéquation du produit au marché. Les subventions peuvent financer un développement précieux tout en étant soumises à des restrictions et à une récurrence commerciale limitée.
La cohorte de clients doit afficher les revenus d'ouverture, les renouvellements, l'expansion, la contraction, le taux de désabonnement, les services, les revenus différés et l'encaissement. Il doit identifier le fournisseur de matériel, la charge de travail, la version du produit et l'assistance spécialisée. La concentration peut être élevée car les premiers clients sont des partenaires stratégiques. L'acheteur doit tester si ces relations survivent à un changement de contrôle ou de stratégie matérielle.
Les prévisions de revenus ne doivent pas supposer qu’une plus grande disponibilité du matériel crée automatiquement une demande. Le modèle doit relier chaque segment de clientèle à une capacité définie, un événement d'adoption et un coût de vente. Les prévisions de marché non étayées devraient rester en dehors du pont de valeur atteinte.
9 Résultats clients en matière de diligence
Les références clients doivent se concentrer sur les décisions et les résultats acceptés. L'acheteur doit se demander quel problème a été résolu, quelle base de référence classique existait, quelle cible a été utilisée, comment les résultats ont été validés, quelles ressources ont été consommées et si le client a modifié une décision opérationnelle. Une collaboration publiée peut avoir une signification stratégique sans établir de valeur économique récurrente.
Les critères d'acceptation doivent être contractuels dans la mesure du possible. Les logiciels de chimie peuvent être jugés par leur précision prédictive et leur validation expérimentale. L'optimisation peut être jugée par la valeur objective, la faisabilité, la durée d'exécution et la répétabilité. Les diagnostics d'erreur peuvent être jugés par la réduction mesurée ou la qualité de la validation. La métrique doit correspondre à l'utilisation du client.
La portabilité doit être testée commercialement. Si le fournisseur d'origine n'est pas disponible ou si la cible est acquise par un fabricant de matériel informatique concurrent, le client peut-il continuer ? L'acheteur doit examiner les obligations de résiliation, d'exclusivité, de données, de propriété des résultats, d'audit et de support.
La preuve la plus solide est une utilisation payante répétée avec des conditions de livraison stables. Le plus faible est une manifestation d’intérêt non signée. L'évaluation doit utiliser une échelle de preuves client plutôt que de placer tous les logos dans la valeur du pipeline.
10 Valoriser le talent et le savoir-faire scientifique
Les équipes de logiciels quantiques peuvent combiner des physiciens théoriciens, des mathématiciens appliqués, des ingénieurs compilateurs, des scientifiques du domaine, des ingénieurs logiciels, des chefs de produits et des scientifiques clients. L'acheteur doit mapper chaque capacité critique aux produits et aux jalons. Les titres organisationnels à eux seuls ne révèlent pas une dépendance technique.
La cible peut s'appuyer sur les fondateurs pour la conception des algorithmes, la crédibilité du client et le réglage manuel. Les ingénieurs clés peuvent posséder le compilateur ou le système de déploiement. Les scientifiques du domaine peuvent traduire les problèmes des clients en formulations résolubles. L'équipe de diligence doit identifier les connaissances non documentées et les délais de remplacement réalistes.
La rétention doit refléter le travail post-clôture. Les récompenses basées sur le service peuvent soutenir la continuité. Les récompenses d'étape doivent utiliser des résultats reproductibles et des résultats acceptés par les clients. La rémunération doit éviter de récompenser une sélection d’indices de référence ou des allégations de performance non étayées.
L'intégration doit préserver le défi scientifique et la discipline de livraison de logiciels. L'acheteur doit définir l'accès au référentiel, la gouvernance des versions, la sécurité, l'autorité en matière d'architecture et la propriété du produit. Un acquéreur de matériel doit éviter de forcer chaque application sur sa propre plate-forme avant de tester la portabilité et la valeur client.
11 Évaluer les risques liés à la cybersécurité et à la chaîne d’approvisionnement logicielle
Les produits logiciels quantiques héritent du risque logiciel classique. L'acheteur doit examiner l'identité, l'accès privilégié, les secrets, les dépendances, créer des pipelines, la signature des packages, la gestion des vulnérabilités, la journalisation, la réponse aux incidents et la récupération. Les jetons cloud et les informations d'identification matérielles nécessitent un contrôle particulier.
Les nomenclatures des logiciels doivent identifier les packages, les versions, les licences et les vulnérabilités connues. Les versions reproductibles et les pipelines de versions protégés réduisent le risque que le produit acquis ne puisse pas être reconstruit ou fiable. L'acheteur doit tester la restauration des sauvegardes et la possibilité de faire pivoter toutes les informations d'identification à la clôture.
Les données client et expérimentales peuvent être sensibles. Les contrats et l'architecture doivent indiquer où sont stockés les entrées, les circuits, les données d'étalonnage et les sorties. La transformation transfrontalière, les contrôles à l’exportation et les exigences sectorielles peuvent affecter l’intégration. Les représentations de sécurité doivent être testées par rapport aux journaux et aux incidents.
Le coût de la remédiation fait partie du plan de valorisation et d’intégration. Un algorithme précieux avec des contrôles logiciels faibles peut nécessiter un travail de référentiel, de cloud et d'identité avant de pouvoir être déployé auprès de clients réglementés. Ces dépenses ne doivent pas être cachées dans une synergie générale.
12 Coût de remplacement du modèle et temps évité
Le coût de remplacement doit estimer l'équipe, les données, l'expérimentation, les logiciels et le temps écoulé requis pour reproduire la capacité transférable. Les dépenses historiques en sont la preuve, mais elles incluent les chemins échoués et les coûts irrécupérables. L'acheteur doit valoriser le système actuel, la documentation et l'apprentissage qui constituent une alternative crédible.
Le modèle doit séparer le volume de code de la difficulté. Un petit passage du compilateur peut coder une expertise rare. Un grand référentiel d'applications peut contenir du code d'intégration remplaçable. Les entretiens avec des experts, l'historique du référentiel et la reproduction des références aident à identifier le goulot d'étranglement.
Le temps gagné peut être précieux lorsqu'une feuille de route matérielle ou industrielle a une fenêtre fixe. L'acquéreur doit comparer le temps d'achat et d'intégration avec une construction interne. L'avantage devrait être réduit lorsque les droits clés, les clients ou le personnel ne peuvent pas être transférés.
Les normes ouvertes et les frameworks open source peuvent réduire les coûts de remplacement. Ils peuvent également élargir le marché et augmenter la valeur de couches propriétaires complémentaires. L'évaluation doit déterminer si la douve de la cible se renforce ou s'affaiblit à mesure que l'interopérabilité s'améliore.
13 Construire le modèle de revenu
Un modèle de revenus doit utiliser les preuves des clients plutôt que des prévisions de marché quantiques à distance. Les revenus doivent être segmentés par produits, services, subventions et autres sources. La marge brute doit inclure l'exécution dans le cloud, l'accès au matériel, la livraison spécialisée, le support et les licences tierces. Les salaires de la recherche et le développement de produits doivent rester visibles.
La prévision doit modéliser les événements de conversion. Un pilote se convertit lorsque l’acceptation, l’approvisionnement et le budget sont satisfaits. Un abonnement se renouvelle lorsque le produit reste utile sur tous les matériels et versions. Un projet de services devient un revenu de produit uniquement lorsque la livraison est reproductible avec moins d'efforts sur mesure.
Le modèle doit inclure les dépendances matérielles. Si un flux de travail précieux nécessite une capacité de fournisseur attendue dans deux ans, les revenus doivent être pondérés selon leurs probabilités et capitalisés avec prudence. Si la cible génère aujourd’hui des revenus grâce à des diagnostics ou à des simulations, les flux de trésorerie obtenus peuvent prendre en charge l’analyse conventionnelle.
La valeur finale doit refléter l'évolution technologique et la concurrence. Une longue période de croissance non prise en charge par les cohortes de clients crée une fausse précision. Le comité de transaction doit comparer l'approche basée sur les revenus avec le coût de remplacement et la valeur du scénario.
14 Utilisez une carte de score ajustée en fonction de la portabilité
La carte de pointage doit couvrir les preuves des algorithmes, la portabilité, la qualité des références, la propriété intellectuelle, les données, les résultats clients, la qualité des revenus, l'équipe, la sécurité et la piste. Chaque score doit être lié à des preuves et à une implication d'évaluation. Un score scientifique élevé ne peut pas réparer un manque de propriété ou une faible acceptation par les clients.
La portabilité doit recevoir des sous-scores distincts pour la source, la sémantique, la compilation, l'exécution, les performances et la continuité commerciale. L'acheteur doit identifier le niveau minimum requis par la thèse d'acquisition. Un acheteur de matériel peut accepter une dépendance qui renforce sa plateforme. Un acheteur de cloud neutre peut exiger une large portabilité des performances.
Le tableau de bord doit montrer la concentration. Une cible peut recevoir des notes moyennes élevées tout en dépendant d'un fournisseur, d'un scientifique ou d'un client. Les échecs de déclenchement doivent donc être signalés séparément des scores pondérés. Le jury doit savoir quel problème peut invalider la thèse.
Les scores devraient changer après les tests de confirmation. Le modèle doit conserver les preuves et la justification de chaque mise à jour. Cela prend en charge la négociation des prix et la responsabilité après la clôture.
15 Apprendre des combinaisons divulguées
La création de Quantinuum a associé Honeywell Quantum Solutions à Cambridge Quantum. Les annonces publiques décrivaient une société intégrée de matériel et de logiciels et un support de fabrication à long terme. Cette combinaison illustre une thèse d'intégration verticale, notamment la capacité de développer des logiciels sur plusieurs plates-formes tout en contrôlant une feuille de route matérielle.
L'acquisition de Quantum Benchmark par Keysight a ajouté un logiciel de diagnostic d'erreurs, de suppression d'erreurs et de validation des performances à un portefeuille quantique plus large. La justification divulguée illustre la valeur d'un logiciel qui mesure et améliore le matériel. Il ne divulgue pas d’évaluation par un algorithme autonome.
Quantum Machines a acquis QDevil pour étendre la capacité de contrôle quantique du niveau de la porte au qubit. SandboxAQ a acquis Good Chemistry pour ajouter une technologie, des clients et des talents en chimie computationnelle. Ces transactions illustrent les thèses de la pile de contrôle et des applications de domaine.
Les exemples ne doivent pas être traités comme des comparables directs sans alignement sur les prix, les revenus, les droits et les preuves. Ils sont utiles pour identifier les voies de valeur stratégiques : intégration verticale, validation, contrôle, flux de travail de domaine, talents et accès client. La cible doit être cartographiée sur l'itinéraire soutenu par ses preuves.
16 Construire la valorisation hypothétique
L’exemple travaillé utilise une cible logicielle quantique totalement hypothétique. Il rapporte USD 18 million de revenus annuels : revenus de produits récurrents USD 11 million, services USD 4 million et subventions et autres revenus USD 3 million. Il dispose de USD 96 million de liquidités sans restriction et de USD 38 million d'utilisation annuelle de liquidités. Ces montants ne représentent pas une entreprise observée.
La valeur centrale de l'entreprise est USD 420 million. Il alloue USD 105 million aux algorithmes et applications validés, USD 90 million aux actifs du compilateur et d'orchestration, USD 60 million aux relations et contrats clients, USD 45 million aux données et flux de travail propriétaires, USD 70 million à l'équipe et au savoir-faire et USD 50 million aux options de la feuille de route. Chaque valeur est une hypothèse de gestion.
Quatre scénarios testent la portabilité. Un cas contraint dans lequel l'algorithme principal reste lié à un fournisseur a une valeur de USD 140 million et une probabilité de 25 pour cent. Un cas de source portable mais à performances variables a une valeur de USD 360 million et une probabilité de 40 pour cent. Un produit portable performant avec des clients réguliers a une valeur de USD 820 million et une probabilité de 27 pour cent. Une plate-forme de catégorie avec un large accès au matériel a une valeur de USD 1.80 billion et une probabilité de 8 pour cent. La valeur illustrative pondérée en fonction de la probabilité est USD 508.4 million avant intégration, financement et dilution.
La différence entre la valeur centrale allouée et la valeur du scénario pondérée en fonction des probabilités expose des hypothèses. Un acheteur doit s'adapter au coût d'intégration, à la fidélisation, au consentement du client, aux contrats de matériel et au financement. Une contrepartie conditionnelle peut aligner le paiement sur les tests de portabilité et la fidélisation des clients.
17 Structurer la réflexion autour des données probantes
Une contrepartie initiale peut payer pour un code, des droits, des flux de trésorerie et une capacité transférables contrôlés. Les paiements différés peuvent dépendre d'une construction propre, d'un benchmark multi-cibles maintenu, de la fidélisation de la clientèle ou de l'acceptation de la sortie du produit. Les récompenses de rétention devraient récompenser le service et le transfert de connaissances.
Les jalons doivent spécifier les objectifs, les versions, les charges de travail, les références, les mesures et un examen indépendant. L’exigence générale selon laquelle les logiciels restent indépendants du matériel suscite des controverses. Un meilleur jalon indique que les charges de travail définies sont compilées et exécutées selon les objectifs convenus tout en respectant les seuils de qualité, de temps et de coût de la solution.
L’accord devrait tenir compte des changements techniques. Un nouveau matériel peut remplacer une cible d'origine. Les règles de substitution devraient préserver l’équivalence économique et empêcher l’une ou l’autre des parties de choisir un test artificiellement facile ou impossible. Les conseillers qualifiés doivent aborder les conséquences comptables, fiscales, en matière d’emploi et de valeurs mobilières.
L'acheteur doit également protéger les données et la continuité du client. Les consentements, les services de transition, l’accès au cloud et les mesures correctives en matière de sécurité peuvent constituer des conditions ou des engagements de clôture. Un séquestre peut combler les lacunes identifiées en matière de droits. Chaque protection doit correspondre à un risque d’évolution de la valeur.
18 Planifiez les cent premiers jours
Les trente premiers jours doivent sécuriser les référentiels, les informations d'identification, les comptes cloud, les données clients et les pipelines de versions. L’acheteur doit confirmer le personnel critique, geler les bases de données probantes et préserver l’accès des prestataires. Les communications client doivent expliquer la continuité sans faire de promesses de performances non étayées.
Les jours trente à soixante devraient reproduire les builds, réexécuter les tests de performance clés, cartographier l'architecture du produit et valider les obligations des clients. L’équipe d’intégration doit séparer les services partagés des travaux scientifiques protégés. Une feuille de route combinée devrait identifier quelles plates-formes restent prises en charge et pourquoi.
Les jours soixante à cent devraient rationaliser les outils qui se chevauchent, approuver la matrice produit et matériel, remédier à la sécurité et tester le transfert de connaissances. Les responsables commerciaux devraient revoir les plans de tarification, de support et de renouvellement. La finance doit concilier les dépenses d’intégration et les progrès réalisés avec le dossier d’investissement.
Le conseil d'administration devrait recevoir un rapport sur la réalisation de la valeur. Il doit montrer les synergies réalisées, les clients préservés, les preuves de portabilité, l'utilisation des espèces, les risques et les prochaines décisions. L’apprentissage technique devrait mettre à jour les hypothèses d’évaluation plutôt que d’être présenté uniquement comme une activité.
Conclusion
La valeur du logiciel quantique n’est pas établie par une étiquette indépendante du matériel. Cela dépend de la mesure dans laquelle les algorithmes, les compilateurs, les flux de travail et les résultats client survivent à un changement dans l'environnement d'exécution. La traduction des sources, la compilation réussie et les performances commerciales équivalentes sont des éléments de preuve différents.
Un acquéreur doit créer une échelle de preuves algorithmique, un graphique de dépendance, une matrice de portabilité, un plan de référence et une cohorte de clients. Il doit reproduire les builds, contrôler les fonctionnalités du fournisseur, mesurer la qualité et le délai de résolution, confirmer les droits et rapprocher les liquidités des clients. Les actifs réalisés doivent être séparés de la valeur conditionnelle de la feuille de route.
Les représentations et normes ouvertes peuvent réduire les coûts de changement tout en exposant les limites de capacités spécifiques à la cible. Les combinaisons stratégiques montrent que les logiciels peuvent créer de la valeur grâce à l'intégration verticale, aux diagnostics, au contrôle et aux applications de domaine. La valeur d’une cible spécifique nécessite toujours des preuves spécifiques à la transaction.
Les conseils peuvent utiliser ce cadre pour décider d’acquérir, d’investir, d’accorder une licence, de s’associer ou de construire. Chaque élément de valeur matérielle doit faire référence à des droits contrôlés, à des performances reproductibles, à des résultats acceptés par les clients ou à une hypothèse de gestion explicitement énoncée. La réflexion devrait évoluer lorsque ces preuves changent.
Annexe A Protocole de test de portabilité
Le protocole doit geler la source, les dépendances, les versions du compilateur, les profils cibles, les données, les graines et les critères d'acceptation. Il doit inclure une cible principale, une alternative crédible et un simulateur ou un émulateur. La cible doit être construite à partir d’un environnement propre en utilisant des informations d’identification et une infrastructure documentées.
Chaque exécution doit enregistrer le temps de compilation, la largeur et la profondeur du circuit, les opérations natives, les tirs, le temps de file d'attente et d'exécution, le post-traitement classique, les tentatives, le coût total et la qualité de la solution. Les exclusions et les échecs doivent rester dans le dossier. Une implémentation de base doit utiliser le même accès et la même configuration.
Le rapport doit classer la source, la sémantique, la compilation, l'exécution, les performances et la portabilité commerciale. Il doit indiquer quelles modifications ont été nécessaires et si elles constituent des branches de produits maintenues. Les examinateurs indépendants devraient avoir un accès suffisant pour reproduire la conclusion.
Annexe B Preuves des clients et des revenus
Le calendrier client doit identifier la contrepartie légale, le produit, la charge de travail, le fournisseur de matériel, la durée, la valeur engagée, les services, l'acceptation, la facturation, la trésorerie, le renouvellement et le changement de contrôle. Le financement et les subventions de la recherche doivent être séparés des revenus récurrents des produits.
L'analyse de cohorte doit montrer les revenus récurrents d'ouverture, les nouveaux clients, l'expansion, la contraction, le désabonnement et la clôture des revenus récurrents. Il doit être rapproché des registres comptables. Le pipeline doit rester en dehors des revenus contractuels et doit identifier les barrières d’approvisionnement, techniques et budgétaires.
Les références clients doivent confirmer la décision prise en charge, la ligne de base, le résultat accepté, l'effort spécialisé et l'intention future. L'acheteur doit vérifier si la relation survit à un changement de matériel ou de propriété.
Annexe C Salle de données d'évaluation
La salle de données techniques doit contenir des référentiels, des instructions de construction, des verrous de dépendance, des nomenclatures de logiciels, des licences, des accords de contributeur, des brevets, des droits sur les données, des références, des enregistrements d'exécution bruts, des configurations cibles, des enregistrements de sécurité et un historique des incidents. Il doit inclure les expériences négatives et échouées.
Les dossiers commerciaux doivent inclure les contrats, les énoncés de travail, les subventions, les factures, les reçus de trésorerie, les journaux d'assistance et l'utilisation. Les registres financiers doivent concilier les catégories de revenus, la marge brute, les dépenses de recherche, la trésorerie, les engagements et l'utilisation mensuelle de la trésorerie.
Le rapport de diligence doit identifier ce qui a été reproduit, échantillonné, indisponible ou contesté. Chaque écart non résolu doit apparaître dans le prix, la structure, le budget d'intégration ou les conditions d'approbation.
Annexe D Grand livre de valeurs d'intégration
Le grand livre de la valeur d’intégration doit distinguer les revenus, les coûts, le capital et les effets stratégiques. Les effets sur les revenus peuvent inclure la fidélisation des clients, les ventes croisées, l'accès à de nouvelles plateformes et une conversion plus rapide des projets pilotes. Les effets en termes de coûts peuvent inclure la suppression d’infrastructures en double, l’effet de levier en matière d’approvisionnement et une réduction des dépenses en licences externes. Les effets financiers incluent l’évitement du développement interne et la réduction du délai jusqu’à la prochaine version du produit. Les effets stratégiques incluent le contrôle d’un compilateur critique, d’un flux de travail, d’un actif de données ou d’une interface client.
Chaque élément doit avoir une référence, un propriétaire responsable, un calendrier, des dépenses requises et une source de preuves. Une estimation brute de synergie doit être réduite pour tenir compte de l'attrition des clients, des interruptions de produits, des récompenses de fidélisation, de la migration vers le cloud, des mesures correctives en matière de sécurité, du support de plate-forme dupliqué et des taxes. Les avantages qui dépendent du matériel futur doivent être pondérés selon leur probabilité et présentés séparément des actions à court terme.
Le grand livre doit éviter les doubles comptes. La portabilité des algorithmes peut favoriser la fidélisation des clients et réduire les coûts de reconstruction, mais le même avantage ne devrait pas apparaître dans les deux lignes sans un rapprochement. L'acheteur doit également distinguer la valeur transférée d'une autre unité commerciale de la valeur créée pour le groupe combiné. Le transfert des coûts du cloud ou de l’ingénierie vers un budget central ne crée pas en soi de valeur pour l’entreprise.
Les rapports post-clôture doivent comparer la valeur réalisée avec le cas approuvé. Les mesures techniques doivent être liées aux résultats commerciaux. Un benchmark multicible réussi a une valeur de transaction limitée jusqu'à ce qu'il réduise les coûts de support, fidélise un client, étende la distribution ou débloque un produit. Un renouvellement de client doit être attribué avec précaution lorsqu'il dépend également des ventes, de l'évolution du matériel ou des prix.
Le conseil d'administration doit examiner le grand livre à intervalles définis et réviser le dossier d'investissement lorsque les preuves changent. La valeur non atteinte devrait déclencher une décision de produit, de capital ou d’intégration. L'objectif est de préserver un lien traçable entre la thèse d'acquisition, les preuves techniques, la trésorerie et l'exécution responsable.
Annexe E Chiffres et tableaux de décisions
Séquence proposée ; chaque étape nécessite un enregistrement reproductible et un test de réception défini.
Hypothèses de gestion entièrement hypothétiques ; Le score combine la qualité, le délai et le coût d’une solution normalisée.
Hypothèses de gestion entièrement hypothétiques ; USD millions.
Hypothèses de gestion entièrement hypothétiques ; USD millions.
Hypothèses de gestion entièrement hypothétiques ; USD millions.
| Couche | Test | Échec commun | Utilisation de la valorisation |
|---|---|---|---|
| Source | Le code traduit ou est exprimé à travers un langage partagé | La syntaxe bouge tandis que les dépendances restent | Preuve de transférabilité limitée |
| Sémantique | L’intention mathématique reste équivalente | Les restrictions de cible modifient la méthode | Ajustement des preuves de l'algorithme |
| Compilation | Le programme descend dans la pile cible | Fonctionnalités de contrôle, de portes ou d'exécution non prises en charge | Coût de reciblage |
| Exécution | Le flux de travail complet s'exécute dans des conditions prises en charge | Service de fournisseur caché ou intervention manuelle | Test de capacité réalisé |
| Performance | La qualité, le délai et le coût restent dans les limites du seuil | La production équivalente devient non rentable | Valeur du produit et de l'option |
| Commercial | Le client accepte, paie et renouvelle | Un changement de matériel ou de propriétaire interrompt l'adoption | Valeur de la relation et du revenu |
Hiérarchie proposée ; chaque couche nécessite ses propres preuves.
| Scène | Enregistrement requis | Vérification indépendante | Traitement de valorisation |
|---|---|---|---|
| Affirmation mathématique | Problème, hypothèses et critère d'exactitude | Avis d'experts | Option recherche uniquement |
| Simulation reproductible | Code, données, graines et référence classique | Rediffusion en environnement propre | Savoir-faire et valeur du code |
| Compilation cible | Enregistrements du compilateur, du profil, du circuit et des ressources | Répéter la construction | Valeur d'implémentation conditionnelle |
| Exécution matérielle | Travaux, calibrage, prises de vue, temps, coût et rendement | Course retenue | Preuve technique obtenue |
| Performances multi-cibles | Objectifs et seuils d’acceptation comparables | Benchmark indépendant | Amélioration de la portabilité |
| Acceptation du client | Contrat, livraison, facture et espèces | Rapprochement clients et comptable | Valeur commerciale |
Séquence de diligence transactionnelle proposée.
| Couche | Preuve | Risque de dépendance | Implication de valeur |
|---|---|---|---|
| Langues et bibliothèques | Dépôts, versions, licences et tests | Modifications cassantes et composants sans propriétaire | Coût de maintenance et de réparation |
| Représentation intermédiaire | Profils, transformations et validation | Sémantique ou fonctionnalités cibles non prises en charge | Ajustement de la portabilité |
| Compilateur et passes | Construction, benchmarks, propriété et documentation | Optimisation spécifique à la cible | Actif atteint ou coût de reciblage |
| Matériel et cloud | Contrats, accès, files d'attente, tarifs et fonctionnalités | Concentration des prestataires et changement de contrôle | Performance et ajustement client |
| Flux de travail classique | Données, HPC, AI, post-traitement et orchestration | La revendication quantique dépend des actifs classiques | Attribuer de la valeur au système complet |
Proposition de révision minimale de la chaîne d'exécution du logiciel.
| Composante de valeur | Montant indicatif | Porte des preuves | Traitement des inconvénients |
|---|---|---|---|
| Algorithmes et applications validés | USD 105 million | Repères et droits reproductibles | Retenue de portabilité |
| Compilateur et orchestration | USD 90 million | Construction propre, cibles de preuves et appropriation | Réserve d'assainissement |
| Relations clients et contrats | USD 60 million | Acceptation, renouvellement, paiement et consentement | Ajustement de la rétention |
| Données et flux de travail propriétaires | USD 45 million | Provenance, droits de mutation et contribution | Déduction des droits |
| Équipe et savoir-faire | USD 70 million | Rétention des rôles critiques et transfert de connaissances | Rétention basée sur les services |
| Options de la feuille de route | USD 50 million | Portabilité financée et jalons client | Contrepartie conditionnelle |
Hypothèses de gestion entièrement hypothétiques ; pas observé les données de l’entreprise ou des transactions.
| Preuve | Ce qu'il prend en charge | Limitation | Utilisation de la valorisation |
|---|---|---|---|
| Collaboration de recherche | Accès et engagement technique | Peut manquer de budget récurrent ou d’acceptation | Preuve de relation |
| Subvention ou récompense | Portée financée et soutien politique | Utilisation restreinte et récurrence limitée | Trésorerie contractuelle avec conditions |
| Pilote rémunéré | Budget client et expérience définie | Le travail sur mesure peut ne pas évoluer | Conversion ajustée selon la probabilité |
| Livraison du produit accepté | Performance par rapport aux critères convenus | N'établit pas de renouvellement | Valeur du contrat et de la livraison |
| Répéter une utilisation payante | Budget permanent et pertinence opérationnelle | Peut rester dépendant du fournisseur | Des preuves de revenus plus solides |
Classification proposée pour la diligence en matière de revenus.
| Mesure | Montant indicatif | Question de diligence | Conséquence de la valorisation |
|---|---|---|---|
| Revenus récurrents des produits | USD 11 million | Renouvellement, marge et portabilité | Aide au revenu |
| Chiffre d'affaires des services | USD 4 million | Effort du fondateur et répétabilité | Ajustement des services |
| Subventions et autres revenus | USD 3 million | Restrictions et récurrence | Séparé du produit multiple |
| Liquidités sans restriction | USD 96 million | Disponibilité et engagements | Réconciliation capitaux propres-valeur |
| Utilisation annuelle des liquidités | USD 38 million | Prochaine porte de preuve et délai de financement | Ajustement de la piste et de la dilution |
Hypothèses de gestion entièrement hypothétiques ; USD millions.
| Zone de décision | Preuve verte | État ambre | État rouge |
|---|---|---|---|
| Portabilité | Les charges de travail retenues respectent les seuils de qualité, de délai et de coût dans les objectifs convenus | Portabilité de la source et de l'exécution avec variation des performances | Allégation marketing sans preuve de cible reproductible |
| Droits | Code, données, licences et droits des contributeurs confirmés | Correction limitée avec coût et date | Capacité critique non possédée ou non transférable |
| Clients | Acceptation payée, renouvellement et rapprochement des espèces | Recherche pilote ou financée avec plan de conversion | Logos ou pipeline traités comme des revenus récurrents |
| Équipe et sécurité | Rôles critiques conservés ; build propre et transfert d'accès réussis | Plan de remédiation et de rétention documenté | Informations d’identification du fondateur ou chaîne d’approvisionnement non sécurisée requises |
| Évaluation | Actifs réalisés et options conditionnelles séparées | Gamme de scénarios large mais explicite | Les prévisions de marché remplacent les preuves |
Cadre décisionnel proposé.
Sources
- Consortium de développement économique quantique, benchmarks de performances orientés applications pour l'informatique quantique. Lire la source principale
- Consortium de développement économique quantique, Exploration d’algorithmes quantiques à l’aide de références de performances orientées applications, 2024. Lire la source principale
- Consortium de développement économique quantique, Comité consultatif technique sur les normes et les mesures de performance. Lire la source principale
- Microsoft Azure Quantum, représentation intermédiaire quantique. Lire la source principale
- Microsoft Azure Quantum, profils cibles QIR dans le kit de développement Quantum, 2026. Lire la source principale
- Microsoft Azure Quantum, Simulateurs quantiques backend de fournisseurs quantiques, 2026. Lire la source principale
- OpenQASM, spécification en direct OpenQASM 3. Lire la source principale
- Croix et collaborateurs, OpenQASM 3 : Un langage d'assemblage quantique plus large et plus profond, ACM Transactions on Quantum Computing, 2022. Lire la source principale
- Amazon Web Services, prise en charge d'OpenQASM sur différents appareils Amazon Braket. Lire la source principale
- Amazon Web Services, fonctionnalités OpenQASM prises en charge par Amazon Braket. Lire la source principale
- IBM Quantum, documentation du transpileur Qiskit. Lire la source principale
- Documentation IBM Quantum, Backend et cible. Lire la source principale
- Google Quantum AI, documentation Cirq. Lire la source principale
- Documentation NVIDIA, CUDA-Q. Lire la source principale
- NVIDIA, documentation du SDK cuQuantum, 2026. Lire la source principale
- Xanadu, documentation PennyLane. Lire la source principale
- Fondation Linux, Alliance QIR. Lire la source principale
- Institut national des normes et technologies, Sciences de l'information quantique. Lire la source principale
- ISO, ISO/IEC 4879:2024 Technologies quantiques ; Vocabulaire. Lire la source principale
- Honeywell, Honeywell Quantum Solutions et Cambridge Quantum finalisent leur regroupement d'entreprises, 2021. Lire la source principale
- Quantinuum, Présentation de Quantinuum, 2021. Lire la source principale
- Quantinuum, déclaration d'enregistrement déposée auprès de la Securities and Exchange Commission des États-Unis, 2026. Lire la source principale
- Keysight Technologies, Keysight Technologies acquiert Quantum Benchmark, 2021. Lire la source principale
- Quantum Machines, Quantum Machines acquiert QDevil, 2022. Lire la source principale
- SandboxAQ, SandboxAQ acquiert Good Chemistry, 2024. Lire la source principale
- Fondation IFRS, IFRS 3 Regroupements d'entreprises. Lire la source principale
- Fondation IFRS, IFRS 13 Évaluation de la juste valeur. Lire la source principale
- Fondation IFRS, IAS 38 Immobilisations incorporelles. Lire la source principale
- Conseil des normes internationales d’évaluation, Normes internationales d’évaluation. Lire la source principale
- Securities and Exchange Commission des États-Unis, Manuel d'information financière. Lire la source principale
- Institut national des normes et de la technologie, cadre de développement logiciel sécurisé SP 800-218. Lire la source principale
- Institut national des normes et technologies, Cybersecurity Framework 2.0. Lire la source principale
