Retour d’expérience : MARGO à l’ACCU on Sea 2026
En juin dernier, trois de nos experts se sont rendus à l’ACCU on Sea 2026. Ce salon international est l’un des rendez-vous majeurs pour la communauté C++, réunissant ingénieurs système, développeurs et membres du comité de standardisation autour des évolutions de notre discipline.
Pendant quatre jours, Prosper Gratian, Thibault Ricord-Marchal et Paul Chaucheprat ont suivi un programme dense de conférences axées sur le Modern C++, la performance temps réel et les architectures système. Cette immersion au cœur de sujets complexes fait partie de la dynamique de notre Pôle EXCELLENCE, dont l’objectif est de maintenir nos practices à la pointe des pratiques d’ingénierie logicielle.
Fidèles à notre culture de la transmission, nos trois consultants ont rassemblé et structuré leurs notes à leur retour en France. L’objectif de ce grand retour d’expérience (REX) est double : enrichir immédiatement nos méthodologies projets et retransmettre l’ensemble de ces connaissances à nos équipes lors d’un Learning Lunch MARGO (LLM) dédié ainsi que d’un futur Meetup.
Cet article propose un condensé technique complet et approfondi des sessions majeures du salon. De la Keynote d’Andrei Alexandrescu aux analyses fines de la microarchitecture ou du pattern Sender/Receiver, voici ce qu’il fallait retenir de l’ACCU 2026.
Focus 1 : concurrence structurée et asynchronisme à l’ACCU on Sea
L’un des sujets majeurs de cette édition 2026 de l’ACCU a été la formalisation de la concurrence structurée et la fin annoncée des anciens modèles asynchrones. L’asynchronisme en C++ possède un historique complexe, marqué par des abstractions souvent inefficaces ou propices aux erreurs. Les sessions dédiées ont permis de dresser un bilan de cet historique pour mieux comprendre la rupture qu’apporte le pattern Sender/Receiver prévu pour C++26.
Le « cimetière » des patterns asynchrones legacy
La session de Robert Leahy (The Async Pattern Graveyard) a mis en lumière les failles architecturales des approches historiques :
- Les approches héritées du C : la fonction
getaddrinfoest bloquante, c’est pourquoi la bibliothèque Carespropose une alternative asynchroneares_getaddrinfo. Cette fonction C, bien qu’asynchrone, repose sur un système de callback et de channel pour la gestion d’erreur, rendant son utilisation complexe. Elle souffre des limites du langage C pour le pattern asynchrone. - Les abstractions natives de la STL : l’utilisation classique de
std::futureetstd::asyncest aujourd’hui considérée comme dépassée (graveyard material). Ces modèles souffrent d’allocations implicites et systématiques sur la heap, de l’absence de gestion native des dépendances de tâches et d’un modèle d’exécution rigide. - La comparaison avec Boost.Asio : bien que Boost.Asio soit largement utilisé en production, le modèle des raw callbacks (rappels bruts) reste complexe à maintenir et particulièrement sujet aux erreurs (error-prone) par rapport aux nouveaux standards basés sur le RAII.
L’avènement de std::execution (Sender/Receiver)
Le paradigme moderne repose désormais sur le pattern Sender/Receiver défini dans std::execution. Son principe fondamental est de découpler totalement la définition du travail de son contexte d’exécution réel (le thread ou le pool de threads qui va l’exécuter).
En limitant les allocations au strict minimum nécessaire, ce framework offre une structure hautement performante pour les environnements multithreadés et les entrées/sorties (I/O) asynchrones à haute performance.
Retours d’expérience : du live coding à la production
Deux sessions clés ont permis de confronter ce framework théorique à la réalité du terrain :
- L’implémentation pratique (Dietmar Kühl) : à travers le live coding d’une interface réseau asynchrone communiquant avec une base de données PostgreSQL, Dietmar Kühl a démontré un cas d’usage complet et réel de ce nouveau framework. Cependant, l’exercice a révélé la complexité actuelle de la mise en œuvre, soulevant de nombreuses discussions sur le volume de code répétitif (boilerplate) nécessaire pour écrire son propre Sender customisé. Le design d’un sender s’avère très orienté utilisateur, car il façonne directement l’écriture de l’algorithme qui en dépend.
- Le refactoring et la localité algorithmique (Roi Barkan) : la session Refactoring Towards Structured Concurrency a mis en avant la transition d’architectures legacy vers la concurrence structurée. L’avantage principal réside dans la facilité à injecter des dépendances aux tâches asynchrones et dans le respect strict du caractère RAII. Ce pattern amène une meilleure localité de nos algorithmes multithreadés, ce qui facilite grandement le raisonnement sur le code et le design global des systèmes concurrents.
Le point de vigilance : l’impact sur les performances
Malgré ces avancées majeures en termes de design, le sujet de la performance reste le point critique actuel du pattern Sender/Receiver. À ce stade, des efforts restent à fournir :
- Côté compilateur : sur l’optimisation du code généré à partir des différents scénarios de senders.
- Côté scheduler : sur la nécessité d’écrire des ordonnanceurs (schedulers) personnalisés et optimisés pour maximiser les gains de performance real par rapport aux solutions existantes.
Focus 2 : synthèse sur la métaprogrammation et C++26
L’introduction de la réflexion standardisée constitue l’un des chantiers les plus attendus et les plus puissants des prochains standards C++. Les échanges de l’ACCU 2026 ont permis de dessiner une vision claire : si ces fonctionnalités offrent des capacités d’abstraction inédites, leur mise en œuvre en production exige une vigilance extrême face aux réalités des compilateurs.
La vision macro : spécialisation et abstractions verbalisables
La Keynote d’ouverture d’Andrei Alexandrescu (The Next 20 Weeks of Systems Engineering) a posé le cadre macroéconomique et technique de ces évolutions. Selon lui, l’impact de l’IA pousse inévitablement à la spécialisation de l’expertise, car le travail généraliste sur les couches superficielles peut désormais être aisément automatisé. Pour pérenniser les bases de code, les systèmes doivent se verbaliser à travers des abstractions claires et communes. C’est précisément ici qu’interviennent les nouveautés du langage :
- Les contrats : pour fournir des obligations d’usage claires.
- La réflexion : pour abstraire et raisonner sur le code lui-même.
- Le hardening de la STL : pour sécuriser les programmes en éliminant les comportements indéfinis (Undefined Behaviors).
Bridge-building : de la réflexion compile-time au runtime
Par définition, la réflexion native de C++26 s’opère strictement au moment de la compilation (compile-time). Cependant, l’ingénierie logicielle réelle (sérialisation gRPC, mapping d’objets dynamiques, liaisons UI) exige souvent de la flexibilité à l’exécution (runtime).
La presentation de Laurie Kirk a introduit CMM (Call Me Maybe), une bibliothèque conçue pour jeter un pont entre ces deux mondes. CMM relève le défi de transitionner des valeurs consteval vers des valeurs statiques au runtime. Sa force réside dans son absence totale de recours au RTTI (Run-Time Type Information). En utilisant des annotations légères et en exploitant les nouvelles fonctionnalités de C++26 — en particulier define_static_objects et les blocs consteval —, CMM permet d’obtenir une réflexion au runtime qui surperforme les bibliothèques legacy tout en minimisant l’impact sur la taille du binaire (binary bloat).
Pour conclure Hana a insisté sur l’effort constant qu’est la mise en constexpr de tout ce qui peut l’être dans le standard. C’était un message pour tout auteur de proposition pour le standard, le compile-time ne devrait pas être une option. En bonus elle a présenté la puissance de sa structure de données favorite : le hashed Array Mapped Trie (HAMT), qui garantit de hautes performances pour la recherche (lookup), l’insertion et la suppression (deletion).
La réalité des compilateurs : le cauchemar de l’IFNDR
Malgré l’enthousiasme général, la session de Dan Katz (Portable Reflection in C++26) a ramené les développeurs à la réalité des implémentations industrielles. Le message est crucial : un standard approuvé ne garantit pas une implémentation uniforme chez tous les éditeurs de compilateurs.
Le point de friction majeur réside dans le fait que GCC et Clang résolvent les templates à des moments totalement différents lors de la compilation d’une unité de traduction. Ce décalage temporel ouvre la porte aux bugs de type IFNDR (Ill-Formed No Diagnostic Required). C’est le scénario catastrophe pour les auteurs de bibliothèques : un code de réflexion peut compiler proprement sur GCC, mais échouer de manière catastrophique ou générer un comportement indéfini sur Clang, le tout sans lever le moindre avertissement à la compilation.
Pour concevoir ou adopter les futures bibliothèques de réflexion C++26, il devient obligatoire d’anticiper l’IFNDR dès le premier jour, de multiplier les tests multi-compilateurs, et de surveiller précisément le moment d’instanciation des templates.
Focus 3 : microarchitecture, modèles mémoire & hardware
L’optimisation des performances en C++ ne peut se faire sans une compréhension fine de la microarchitecture des processeurs. À ce niveau d’ingénierie, la complexité algorithmique théorique s’efface souvent devant la réalité physique de la gestion du cache et de l’exécution des instructions par le CPU.
Pipeline CPU et Out-of-Order Execution (OoOE)
La session d’Ofek Shilon (Processor Design and Memory Models) a détaillé comment les processeurs modernes exécutent les instructions et maintiennent une vue à jour sur le contenu de leurs caches. Pour maximiser l’efficacité, les CPU exécutent les instructions dans un ordre différent de celui du code source (Out-of-Order Execution) grâce à des composants hardware spécifiques :
- La Register Alias Table (RAT) : qui gère le renommage des registres pour éliminer les fausses dépendances de données.
- Le Reorder Buffer (ROB) : qui garantit que, malgré une exécution dans le désordre, les instructions sont validées et appliquées dans l’ordre correct d’origine.
Cependant, cette mécanique sophistiquée s’accompagne de contraintes strictes dès lors que l’on manipule des opérations atomiques ou du code multithreadé. Les pipelines du CPU et les moments exacts où entrent en jeu les instructions atomiques conditionnent l’efficacité du programme. Une mauvaise utilisation des atomiques peut bloquer ces mécanismes matériels, provoquant des chutes de performance importantes.
La prédiction de branche et la gestion des caches
Matt Godbolt, lors de sa session Microarchitecture: What Lies Beneath, est allé encore plus loin dans le reverse engineering du micrologiciel des CPU pour comprendre l’utilisation des tables internes et la mise en cache.
L’un des enseignements majeurs est le coût critique lié à la prédiction de branche. Perturber la prédiction de branche — ou l’invalider complètement — détruit les performances. Par exemple, le phénomène de False Sharing force le CPU à invalider l’intégralité de ce qu’il a mis en cache afin de synchroniser les cœurs, ce qui fait perdre tout le bénéfice des prédictions matérielles.
Une discussion directe avec Matt Godbolt a d’ailleurs permis de faire la lumière sur l’optimisation par PGO (Profile-Guided Optimization). Il s’avère très difficile de mettre en place efficacement la PGO dans des contextes simples. Nos compilateurs et nos processeurs sont devenus si performants que le cas de base et la prédiction de branche naturelle sont souvent plus proches du temps d’exécution réel (runtime) que ce qu’on essaie de prédire avec la PGO. Pour que la PGO apporte un réel gain, il faut se trouver dans des situations où la masse de code exécuté dépasse ce que le CPU peut conserver en cache, un scénario complexe à concevoir.
Primitives de synchronisation et Memory Models
Pour résoudre les incohérences de cache générées par l’exécution spéculative et le multithreading, Ofek Shilon a rappelé le rôle des primitives de synchronisation :
- Les fences (barrières mémoire).
- Les opérations de type load-acquire et store-release.
- Les instructions read-modify-write.
En performance pure, si le code ne respecte pas l’alignement ou engendre des cache misses systémiques, le meilleur algorithme théorique sera surclassé par un code plus simple mais mieux adapté au matériel.
Focus 4 : synthèse de nos experts sur la gestion du Legacy
Le dernier volet de l’ACCU 2026 s’est concentré sur la frontière entre les promesses du langage et la réalité de leur exécution, ainsi que sur l’outillage industriel nécessaire pour faire évoluer le code existant sans introduire de régressions.
L’illusion des « Zero-Cost Abstractions »
La session de Steve Sorkin (When Zero-Cost Abstractions Aren’t Zero-Cost) a bousculé une idée reçue en C++. En théorie, une abstraction à coût zéro ne doit induire aucune perte de performance au runtime. Dans la pratique, le compilateur peut éprouver des difficultés à optimiser certaines syntaxes pourtant très claires, comme les std::views ou les ranges de la STL.
Steve Sorkin a illustré ce problème en analysant le code assembleur généré. Par exemple, l’enchaînement de plusieurs filtres entrecoupés d’une transformation (filter | transform | filter) perturbe fortement le compilateur. Au lieu de fusionner les opérations, le compilateur génère un code qui parcourt la chaîne plusieurs fois, ce qui engendre un coût machine important par rapport à une boucle classique. La conclusion est claire : pour valider une abstraction, l’étude de l’assembleur et la mesure terrain restent indispensables.
Dangers des optimisations et Undefined Behaviors (UB)
Robert C. Seacord (membre du comité C) a démontré comment les optimisations agressives du compilateur peuvent s’avérer destructrices lorsqu’elles entrent en collision avec des Undefined Behaviors.
Le cas d’école présenté concernait la suppression automatique des vérifications de pointeurs nuls (null pointer checks). Si un pointeur est déréférencé au début d’une fonction, le compilateur part du principe que ce pointeur est valide. Par conséquent, il supprime purement et simplement tous les tests de sécurité if (ptr == nullptr) situés plus bas dans la fonction. Si le déréférencement initial ne fait pas planter le programme, le garde-fou disparaît, ouvrant la voie à des failles de sécurité majeures. Ce bug exact est survenu au sein du noyau Linux. La recommandation est d’activer systématiquement les avertissements (warnings) du compilateur.
Modernisation industrielle du Legacy : LLM vs Scripts
La session de Peter Muldoon (Modernizing Legacy Codebases without Stopping the World) a apporté un éclairage très pragmatique sur la gestion du code patrimonial à grande échelle. Moderniser une base de code massive ne peut pas se faire de manière magique ou entièrement automatisée via les LLM ou exclusivement clang-tidy.
La solution efficace a consisté à faire travailler ces deux approches main dans la main. Le LLM a été utilisé pour générer des scripts d’automatisation déterministes. Cette méthode presents plusieurs avantages :
- Fiabilité : elle libère le processus du caractère non déterministe et des hallucinations des LLM.
- Auditabilité : un script est un morceau de code sur lequel un ingénieur peut raisonner, tester et valider sur un cas précis.
- Industrialisation : les scripts permettent de découper le chantier en revues de code (PR/Commits) distinctes, facilitant la contribution collective et le suivi du projet.
En marge de ces méthodologies, la session de Tim Condon (Incrementally migrating C++ to a memory safe language) a mis en évidence que les autres langages s’efforcent de concevoir des ponts robustes avec le C++ pour garantir une meilleure interopérabilité.
Les fondamentaux face aux ruptures de demain
L’ACCU on Sea 2026 aura agi comme un excellent snapshot des trajectoires futures du C++ et de l’ingénierie système. L’arrivée imminente de fonctionnalités de rupture comme le modèle de concurrence std::execution (C++26) ou la réflexion standardisée montre que le langage gagne massivement en puissance expressive et en abstractions. Cependant, les retours d’expérience de nos experts soulignent une réalité cruciale : la marge d’erreur architecturale se réduit.
Qu’il s’agisse de contourner les divergences temporelles des compilateurs (le piège de l’IFNDR), de mesurer le coût réel des abstractions à coût zéro ou de composer au quotidien avec les contraintes physiques des microarchitectures CPU (caches, OoOE, prédictions de branche), la seule et unique règle reste la maîtrise des fondamentaux hardware et la mesure terrain. L’hyper-spécialisation technique n’est plus une option, c’est l’atout indispensable pour concevoir des systèmes hautement performants, résilients et viables à long terme.
Échanger avec un expert MARGOPourquoi le pattern Sender/Receiver (std::execution) va-t-it remplacer std::async et std::future ?
Les abstractions historiques comme std::future souffrent d’allocations implicites systématiques sur la heap, d’un manque de concurrence structurée et de profils de blocage trop rigides. Le pattern Sender/Receiver de C++26 résout nativement ces failles en découplement totalement la définition du travail de son contexte d’exécution. Il offre ainsi un framework hautement efficace et sans allocation mémoire superflue pour les environnements multithreadés à haute performance.
Qu’est-ce que le piège de l’IFNDR lié à la réflexion C++26 ?
L’IFNDR (Ill-Formed No Diagnostic Required) is le principal point de vigilance pour les futures bibliothèques de réflexion. GCC et Clang résolvant les templates à des moments différents lors de la compilation, un code de réflexion peut compiler proprement sur l’un mais générer des comportements indéfinis catastrophiques sur l’autre, sans lever le moindre avertissement. Une analyse fine du moment d’instanciation des templates (types complets, types de retour) est obligatoire dès le premier jour.
Pourquoi l’optimisation par PGO (Profile-Guided Optimization) est-elle difficile à appliquer en contexte simple ?
Les processeurs et compilateurs modernes sont devenus tellement performants que la prédiction de branche naturelle à l’exécution est souvent très proche de l’optimum. Pour que la PGO apporte un réel gain de performance, il faut se trouver dans des cas très spécifiques où la masse de code exécuté dépasse largement ce que le CPU est physiquement capable de conserver dans ses caches.
Comment un déréférencement précoce de pointeur peut-il détruire un test de sécurité nullptr ?
Si un pointeur est déréférencé au début d’une fonction, le compilateur applique une optimisation agressive en partant du principe que ce pointeur est valide, sous peine de provoquer un crash immédiat. Par conséquent, il supprime automatiquement tous les garde-fous if (ptr == nullptr) situés plus bas. Si le déréférencement initial n’interrompt pas le processus, la sécurité disparaît face au compilateur (un écueil qui a notamment touché le noyau Linux).
Quelle est la meilleure stratégie pour mener une modernisation de code Legacy à l’aide des LLM ?
L’expérience montre qu’utiliser un LLM directement pour modifier une base de code massive échoue en raison de son caractère non déterministe. La bonne pratique consiste à utiliser le LLM pour concevoir des scripts d’automatisation spécifiques et déterministes. Un script est un code auditable par un ingénieur, ce qui permet d’industrialiser les modifications via des revues de code (PR/Commits) bien séparées et faciles à valider.
Practice Software Engineering
Rejoindre la Practice Software Engineering chez MARGO, c’est intégrer un collectif de 80 passionnés de la tech. Notre ambition : allier l’exigence technique à la force de la communauté pour concevoir des solutions logicielles robustes et innovantes.
- Tribu et écosystème : un accompagnement par 3 Practice Leaders et l’intégration d’une communauté dédiée (C++, Java, C#/Python) pour échanger lors de meetups et afterworks.
- Apprendre et grandir : 100 % de nos collaborateurs formés chaque année (C# Academy, universités mondiales, places pour Devoxx/Devfest) et un coaching ciblé sur les soft skills.
- S’investir et rayonner : un tremplin pour votre personal branding (articles, webinars, presse) et des engagements forts (mécénat de compétences Latitudes, Open Data University).
Un projet C++ complexe ? Contactez nos experts.
Envie de rejoindre le Pôle EXCELLENCE? Discutons-en.
