Je suis Ronan, et je dirige l’ingénierie logicielle quantique chez Equal1. Nous concevons et construisons des ordinateurs quantiques entièrement intégrés grâce à une technologie de pointe basée sur le spin. Equal1 possède des bureaux en Irlande, aux États-Unis, au Canada, au Japon, en Roumanie et aux Pays-Bas, où je réside. Auparavant, je travaillais chez Qblox, une entreprise spécialisée dans les systèmes de contrôle quantique.
Chez Equal1, je me consacre au développement de l’ensemble du système qui fait fonctionner notre ordinateur quantique haute performance RacQ. Ce système est conçu pour gérer des milliers de qubits logiquement corrigés, voire plus. Certains le considèrent comme le « cerveau » des processeurs quantiques (QPU).
Je trouve mon travail passionnant car chaque jour m’apporte de nouvelles connaissances, et j’ai la chance de collaborer avec des collègues formidables et très compétents. J’ai créé ce blog pour partager ce que j’ai appris, bien sûr sans dévoiler aucun secret !
N’hésitez pas à m’envoyer un courriel à ronan ou connectez-vous sur LinkedIn si vous voulez en savoir plus !
***Disclaimer: While I work at Equal1 by the day, this blog is a personal project and does not reflect the views of my employer. The thoughts, ramblings, and opinions shared here are mine alone and haven’t been vetted, approved or modified by anyone but myself.
***Aperçu de l’architecture système
Link to heading
Chez Qblox, j’occupais le poste d’architecte système. Vous trouverez ci-dessous une note de service décrivant les fonctions que j’exerçais alors.
C’est une question qui m’est souvent posée : que doit faire exactement un architecte système ? La réponse varie selon l’entreprise, le pays d’implantation et le secteur d’activité. Cependant, un concept demeure constant : la communication.
Oui, le rôle de l’architecte est de communiquer des idées complexes de manière simple, que ce soit aux équipes de développement et d’ingénierie, aux dirigeants ou aux clients. Cela commence par la compréhension du problème avec le client et l’équipe produit, ce qui est passionnant : créer une solution qui satisfait pleinement le client !
Vient ensuite l’analyse classique des exigences système et, souvent, une phase de prototypage pour valider le concept, où je suis généralement très impliqué. Puis, le développement produit, où j’assure la direction technique et travaille avec des équipes pluridisciplinaires jusqu’à ce que le produit soit prêt. Enfin, le service après-vente du produit est assuré.
Comment parvenir à une décision architecturale ? Le rôle de l’architecte n’est pas nécessairement de décider, mais plutôt de cadrer le problème en regroupant les informations nécessaires à la prise de décision. Par exemple, l’équipe produit (« Quel est le coût de développement de ce nouveau produit ? Quel est le délai de commercialisation ? ») ou la direction (« Souhaitons-nous investir dans cette nouvelle technologie ? Quel est le retour sur investissement et la stratégie à long terme ? »).
Il s’agit d’adopter une approche cartésienne en analysant et en définissant les avantages et les inconvénients de chaque solution possible sans porter de jugement subjectif. Il s’agit également d’évaluer le rapport coût-bénéfice, en tenant compte non seulement de l’effort de mise en œuvre, mais aussi de la maintenance à long terme, des coûts d’exploitation et de la charge cognitive pour l’équipe.
Plus important encore, il s’agit aussi de négocier l’alignement social, car toute décision architecturale que les ingénieurs rejettent ou que les chefs de produit ne comprennent pas est vouée à l’échec. Prendre une décision implique d’impliquer les équipes. Pour le cycle Produit et Métier, assurez-vous que le choix apporte de la valeur ajoutée à l’entreprise. Pour le cycle d’ingénierie, sollicitez l’avis des ingénieurs seniors afin qu’ils s’approprient sa mise en œuvre.
Pour toutes les entreprises proposant un logiciel, la question de la refactorisation est récurrente : pourquoi et quand faut-il procéder à une refactorisation ? On a souvent tendance à penser que lorsque les produits existants sont lents et instables, et que la correction des problèmes liés à la dette technique accumulée prend trop de temps, il est temps de refactoriser. Mais la réponse n’est pas toujours la bonne ; le rôle de l’architecte est plutôt de prévenir l’effet de « second système ».
Ma philosophie personnelle consiste à appliquer les décisions prises dès le premier jour (https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/) et à les évaluer selon le principe de la « porte à double sens » : la refactorisation est-elle irréversible (quasiment impossible à annuler, comme le choix d’un paradigme de base de données principal) ou réversible (facile à modifier ultérieurement, comme le choix d’une bibliothèque interne) ? Les portes à sens unique nécessitent une validation approfondie ; les portes réversibles, de la rapidité.
De prime abord, le rôle de l’analyste système est également de défendre une culture d’ingénierie appropriée qui crée de la valeur à la fois pour les équipes d’ingénierie (moins de gestion des urgences) et pour les équipes produit (délai de mise sur le marché plus court).
Bien que l’idée générale soit d’investir maintenant dans votre pile d’ingénierie/logiciels pour gagner du temps plus tard dans le développement, le véritable défi consiste à trouver le juste équilibre entre investissement et sur-ingénierie : développer les bons outils et composants logiciels pour faciliter le développement et la maintenance du produit, plutôt que de sur-ingénierie quelque chose qui n’ajoute pas de valeur.
Cela signifie également que l’architecte doit communiquer fréquemment avec les équipes produit et la direction afin de promouvoir le travail des équipes qui investissent leurs efforts dans une ingénierie pérenne et adaptée au futur, au lieu de constamment éteindre des incendies.
À un certain moment, la refonte du système ne suffit plus, car la loi de Conway entre en jeu : « Toute organisation qui conçoit un système produira une conception dont la structure est une copie de la structure de communication de l’organisation. »
La solution ne consiste pas toujours à déplacer les équipes, mais plutôt à réaligner leur production sur l’organisation de l’entreprise, de sorte que la synergie des deux équipes soit supérieure à la somme de leurs parties. Si une équipe ne crée pas suffisamment de valeur en raison d’une communication inefficace, il convient de mettre en place un système où ses résultats sont définis par des composants de meilleure qualité et des promesses d’API plus claires, apportant ainsi une plus grande valeur ajoutée à l’entreprise. Et si l’équipe ne parvient pas à créer de nouveaux composants, il faut décomposer le travail en composants plus simples, assortis de promesses d’API plus directes.
Mais surtout, il s’agit de favoriser l’alignement social entre l’équipe et l’organisation : imaginez une entreprise où l’équipe évolue pour créer davantage de valeur. Ne serait-ce pas la situation idéale ?
L’IA et la boucle de conception
Link to heading
Comment l’IA a-t-elle changé ma façon de travailler ? Énormément ! Tout comme les développeurs pratiquent le « vibe-coding », les architectes doivent être plus à même de rédiger des « vibe designs » (ainsi que des « vibe system requirements ») qui peuvent être directement intégrées aux LLM comme entrée pour produire du code.
L’IA est d’une grande aide lors de l’itération sur la conception, car elle peut générer rapidement de nombreuses variantes d’un même design, permettant ainsi d’explorer plus rapidement différentes options. Ces designs peuvent ensuite être rapidement prototypés afin de vérifier leurs hypothèses et la complexité de leur développement.
Mais surtout, il est essentiel de se rappeler que l’IA n’est pas là pour remplacer les ingénieurs, mais pour enrichir leurs compétences et leur créativité. C’est un outil destiné à améliorer le processus de conception, et non à se substituer au jugement et à l’expertise des ingénieurs.
Par exemple, examinez le schéma ci-dessous : combien de spécialistes en logique quantique (LLM) vous diront que le schéma de droite montre une erreur sur le qubit 3 ( Z₂Z₃ ), alors qu’il s’agit en réalité d’une erreur byzantine sur les qubits 1 et 2 ? (explications complètes)
***Quelques illustrations sélectionnées
Link to heading