🔝 Retour au Sommaire
Le C++ est standardisé par le comité ISO/IEC JTC1/SC22/WG21, communément appelé WG21. C'est un comité de travail de l'Organisation internationale de normalisation (ISO) dont la mission est de développer et maintenir le standard international du langage C++ (ISO/IEC 14882).
WG21 est composé de plusieurs centaines de participants actifs, issus d'horizons variés : ingénieurs de grandes entreprises technologiques (Google, Microsoft, Meta, Apple, Bloomberg, NVIDIA, Intel, Qualcomm), développeurs de compilateurs (GCC, Clang/LLVM, MSVC, EDG), universitaires, consultants indépendants, et développeurs passionnés. La participation se fait via les organismes nationaux de normalisation — l'ANSI pour les États-Unis, le BSI pour le Royaume-Uni, l'AFNOR pour la France, le DIN pour l'Allemagne — qui délèguent des représentants au comité international.
Le travail technique est réparti entre plusieurs sous-groupes spécialisés, chacun responsable d'un domaine du langage.
CWG (Core Working Group) — Responsable du langage lui-même : syntaxe, sémantique, résolution des ambiguïtés, et rédaction du texte normatif pour les fonctionnalités du "core language". C'est le CWG qui traite les Contrats, le Pattern Matching, la Réflexion statique, et toute modification aux règles du langage. Présidé historiquement par des experts en specification formelle, le CWG est réputé pour la rigueur de ses reviews.
LWG (Library Working Group) — Responsable de la bibliothèque standard. C'est le LWG qui traite std::execution, std::expected, std::flat_map, std::print, std::generator, et toute addition ou modification à la STL. Le LWG travaille en étroite collaboration avec le CWG quand une fonctionnalité de librairie requiert des modifications au langage (comme ce fut le cas pour std::format et les constexpr containers).
EWG (Evolution Working Group) — Responsable de l'évaluation des proposals de nouvelles fonctionnalités du langage. Avant qu'une proposal atteigne le CWG pour la rédaction formelle, elle doit d'abord convaincre l'EWG de sa pertinence, de son design et de sa faisabilité. L'EWG est le premier filtre technique pour les idées nouvelles touchant au core language.
LEWG (Library Evolution Working Group) — L'équivalent de l'EWG pour la bibliothèque standard. Le LEWG évalue les proposals de nouvelles composantes de librairie avant de les transmettre au LWG pour la rédaction du texte normatif.
En parallèle des groupes principaux, WG21 maintient des Study Groups thématiques dédiés à l'exploration de domaines spécifiques. Ces groupes sont le lieu où les idées encore immatures sont discutées, affinées et développées avant d'être soumises comme proposals formelles. Parmi les Study Groups les plus actifs :
-
SG1 (Concurrency) — Concurrence, parallélisme, atomiques, modèle mémoire. C'est le SG1 qui a piloté le travail sur
std::execution(Senders/Receivers) pendant plusieurs années avant son intégration en C++26 (voir section 12.14.4). -
SG2 (Modules) — Système de modules C++20 et ses évolutions. Le travail continue pour résoudre les limitations restantes et améliorer l'intégration avec les build systems (voir section 12.13).
-
SG6 (Numerics) — Types numériques, arithmétique à virgule fixe, nombres à précision étendue. Un domaine pertinent pour la finance quantitative et le calcul scientifique.
-
SG7 (Reflection) — Réflexion compile-time. Ce Study Group a produit le travail qui a abouti à la réflexion statique de C++26 (voir section 12.14.2) et continue d'explorer les extensions pour C++29.
-
SG12 (Undefined and Unspecified Behavior) — Un groupe critique pour la sécurité du langage, qui travaille à réduire les comportements indéfinis et à clarifier les garanties du standard.
-
SG15 (Tooling) — Outillage, build systems, package management. Un domaine historiquement négligé par le comité qui prend de l'importance avec la complexité croissante des chaînes de build C++ (voir sections 26–28).
-
SG21 (Contracts) — Le groupe qui a piloté la conception des Contrats C++26 (voir section 12.14.1). Ses travaux se poursuivent pour les extensions prévues dans les standards futurs.
-
SG22 (C/C++ Liaison) — Coordination entre les comités C et C++ pour maintenir la compatibilité et faciliter l'interopérabilité (voir section 43.1).
-
SG23 (Safety and Security) — Créé en réponse aux préoccupations croissantes sur la sécurité mémoire du C++, ce groupe travaille sur les Safety Profiles et les mécanismes de hardening (voir section 45.6).
Les Study Groups ne produisent pas directement du texte normatif. Leur rôle est exploratoire : ils développent une idée, la formalisent en proposal, puis la transmettent à l'EWG/LEWG pour évaluation et, si elle est acceptée, au CWG/LWG pour intégration dans le standard.
Avant C++11, le comité n'avait pas de calendrier fixe. C++03 est arrivé cinq ans après C++98 comme une correction mineure, et le successeur — initialement baptisé "C++0x" dans l'espoir d'une livraison avant 2010 — a finalement été publié en 2011, treize ans après C++98. Ce retard considérable a convaincu le comité d'adopter un cycle de publication triennal pour éviter que les standards ne deviennent des projets interminables accumulant des fonctionnalités.
Le principe est simple : un nouveau standard est publié tous les trois ans, avec un contenu déterminé par ce qui est prêt à la date du feature freeze. Les fonctionnalités qui ne sont pas suffisamment matures sont reportées au cycle suivant plutôt que de retarder la publication.
| Standard | Année | Surnoms | Fonctionnalités marquantes |
|---|---|---|---|
| C++98 | 1998 | — | Premier standard ISO. STL, templates, exceptions |
| C++03 | 2003 | — | Corrections techniques mineures |
| C++11 | 2011 | "Modern C++" | Move semantics, lambdas, auto, smart pointers, threads |
| C++14 | 2014 | — | Corrections et extensions de C++11 (lambdas génériques, make_unique) |
| C++17 | 2017 | — | std::optional, std::variant, structured bindings, std::filesystem, if constexpr |
| C++20 | 2020 | "Le grand cru" | Concepts, Ranges, Coroutines, Modules, std::format, std::jthread |
| C++23 | 2023 | — | std::expected, std::print, std::flat_map, std::mdspan, std::generator, std::stacktrace |
| C++26 | 2026 | — | Contrats, Réflexion statique, Pattern Matching, std::execution |
| C++29 | 2029 (prévu) | — | En cours de définition |
Chaque cycle triennal suit un rythme interne structuré en phases :
Phase d'exploration (année 1) — Les Study Groups explorent les sujets, les proposals initiales sont soumises, et l'EWG/LEWG évaluent les directions possibles. C'est la phase la plus ouverte, où les idées les plus ambitieuses sont discutées.
Phase de convergence (année 2) — Les proposals retenues sont affinées, les designs sont stabilisés, et les premières rédactions de texte normatif sont produites. Le comité commence à identifier les fonctionnalités qui seront prêtes à temps et celles qui devront être reportées.
Phase de finalisation (année 3) — Le feature freeze intervient généralement 12 à 18 mois avant la date de publication prévue. Après le feature freeze, seules les corrections, les clarifications et les ajustements de rédaction sont acceptés. Le draft passe par une phase de relecture intensive (Committee Draft, puis Draft International Standard), suivi du vote de ratification par les organismes nationaux.
Pour C++29, cela signifie concrètement :
- 2026–2027 : Exploration et premières proposals
- 2027–2028 : Convergence et feature freeze (probablement mi-2028)
- 2028–2029 : Finalisation, relecture, vote
- 2029 : Ratification et publication
Comprendre comment une idée devient une fonctionnalité du standard est essentiel pour interpréter correctement les discussions du comité et calibrer ses attentes.
Tout commence par un paper — un document technique soumis au comité, identifié par un numéro de la forme Pnnnn (par exemple, P2996 pour la réflexion statique). N'importe qui peut soumettre un paper, bien qu'en pratique la plupart soient rédigés par des participants réguliers du comité. Le paper décrit le problème à résoudre, la solution proposée, les alternatives considérées, et l'impact sur le standard existant.
Les papers sont publiés sur open-std.org sous forme de mailings trimestriels (pre-meeting et post-meeting), et sont librement accessibles.
Si la proposal touche un domaine couvert par un Study Group, elle y est d'abord discutée. Le SG évalue la pertinence du problème, la qualité de la solution, et les interactions avec les autres travaux en cours. Le paper est souvent révisé plusieurs fois (P2996R0, P2996R1, P2996R2…) en réponse aux retours du groupe. À chaque révision, le numéro de révision s'incrémente.
Quand le Study Group estime que la proposal est suffisamment mature, elle est transmise à l'EWG (pour les fonctionnalités du langage) ou au LEWG (pour les fonctionnalités de librairie). Ces groupes d'évolution évaluent le design global : est-ce la bonne solution ? Le design est-il cohérent avec le reste du langage ? Les compromis sont-ils acceptables ? Y a-t-il des objections de fond ?
L'EWG/LEWG vote sur la direction du design, demande souvent des révisions, et finit par approuver (ou rejeter) le transfert vers le groupe de rédaction.
Le CWG (pour le langage) ou le LWG (pour la librairie) prend en charge la rédaction du texte normatif — le "wording" qui sera intégré dans le standard. Cette étape est d'une exigence particulière : le texte doit être précis, non ambigu, et cohérent avec les milliers de pages existantes du standard. Des problèmes de rédaction à ce stade peuvent retarder significativement une fonctionnalité ou révéler des ambiguïtés de design non détectées précédemment.
Une fois le wording approuvé par le CWG/LWG, la proposal est soumise au vote en session plénière du comité. Un vote favorable intègre la fonctionnalité dans le working draft — le brouillon du prochain standard. L'intégration dans le working draft ne signifie pas que la fonctionnalité est définitive : elle peut encore être modifiée ou, dans de rares cas, retirée avant la ratification finale.
Le working draft finalisé passe par les procédures ISO formelles : Committee Draft (CD), Draft International Standard (DIS), et vote final (FDIS) par les organismes nationaux. En cas de commentaires négatifs, des ajustements sont apportés et un nouveau vote est organisé. La publication officielle du standard intervient après le vote positif final.
Le parcours complet — de la première soumission au standard publié — prend typiquement 3 à 10 ans selon la complexité et le degré de consensus. Les fonctionnalités simples et non controversées (comme std::make_unique, ajouté en C++14) peuvent traverser le processus en un à deux cycles. Les fonctionnalités complexes et controversées (comme les Contrats ou les Modules) peuvent prendre une décennie ou plus.
Voici quelques exemples concrets qui illustrent la variabilité :
| Fonctionnalité | Première discussion | Standard final | Durée |
|---|---|---|---|
std::make_unique |
~2013 | C++14 | ~1 an |
| Concepts | ~2003 (premiers papers) | C++20 | ~17 ans |
| Ranges | ~2013 (Eric Niebler) | C++20 | ~7 ans |
| Modules | ~2007 (premiers papers) | C++20 | ~13 ans |
| Contrats | ~2014 (premiers papers) | C++26 | ~12 ans |
| Réflexion statique | ~2013 (premiers papers) | C++26 | ~13 ans |
std::expected |
~2017 | C++23 | ~6 ans |
std::print |
~2019 | C++23 | ~4 ans |
WG21 se réunit trois fois par an en sessions plénières d'une semaine (du lundi au samedi). Ces réunions sont le moment où les votes formels sont pris, où les proposals avancent d'une étape à l'autre, et où les discussions en face à face permettent de résoudre des désaccords que les échanges écrits n'ont pas tranchés.
Les réunions se tiennent en alternance entre l'Amérique du Nord, l'Europe et l'Asie-Pacifique, afin de répartir la charge de déplacement entre les participants des différentes régions. Des exemples de lieux récents incluent des villes comme Kona (Hawaï), Varna (Bulgarie), Tokyo, St. Louis, ou Wrocław (Pologne).
Le travail ne s'arrête pas entre les réunions plénières. Les Study Groups, l'EWG, le LEWG, le CWG et le LWG tiennent des sessions de télétravail régulières (généralement toutes les deux semaines) pour avancer sur les proposals en cours. Les discussions se poursuivent aussi sur les listes de diffusion du comité et, de plus en plus, sur GitHub.
Après chaque réunion plénière, des participants publient des trip reports — des comptes rendus accessibles qui résument les décisions prises, les proposals avancées ou rejetées, et les tendances de fond. Ces rapports sont la source la plus efficace pour suivre l'actualité du comité sans lire les papers techniques ni assister aux réunions.
Les trip reports sont publiés sur divers canaux : blogs personnels de membres du comité, Reddit r/cpp (voir section 48.4.2), et le site meetingcpp.com (voir section 48.2.2). Quelques auteurs de trip reports réguliers et de qualité sont devenus des sources de référence dans la communauté. Rechercher "C++ committee trip report" suivi de l'année et du lieu de la réunion (par exemple "C++ committee trip report 2026 Tokyo") sur un moteur de recherche suffit généralement à les trouver.
Les documents du comité suivent une nomenclature spécifique qu'il est utile de connaître pour naviguer dans les archives.
Pnnnn — Les "P-papers" sont les proposals de fonctionnalités, les rapports techniques, et les documents de design. C'est le format utilisé depuis 2014. Exemples : P0709 (exceptions déterministes), P2300 (std::execution), P2996 (réflexion statique). Le suffixe Rn indique le numéro de révision : P2996R0 est la version initiale, P2996R7 est la septième révision.
Nnnnn — Les "N-papers" sont l'ancien format, utilisé avant 2014 et encore utilisé pour certains documents administratifs. Exemples : N4950 (le working draft de C++23), N4971 (le working draft de C++26).
Dnnnn — Les documents de direction et les rapports administratifs du comité.
Quand un trip report ou un article mentionne un numéro comme "P2300R10", on peut retrouver le document correspondant en le recherchant sur open-std.org ou directement via un moteur de recherche. La section 48.3.2 détaille les méthodes pour naviguer efficacement dans cette documentation.
| Élément | Détail |
|---|---|
| Comité | ISO/IEC JTC1/SC22/WG21 |
| Participants | Plusieurs centaines (entreprises, universités, individus) |
| Groupes principaux | CWG, LWG, EWG, LEWG |
| Study Groups actifs | SG1, SG2, SG6, SG7, SG12, SG15, SG21, SG22, SG23 et autres |
| Réunions plénières | 3 par an, une semaine chacune |
| Cycle de publication | Triennal (tous les 3 ans depuis C++11) |
| Prochain standard | C++29 (ratification prévue en 2029) |
| Feature freeze C++29 | Estimé mi-2028 |
| Source primaire des papers | open-std.org |
| Suivi accessible | Trip reports post-réunion |
💡 Note : Le processus de standardisation C++ peut sembler labyrinthique vu de l'extérieur, mais il suit une logique interne cohérente : exploration → évaluation → rédaction → vote → ratification. Chaque étape a un rôle précis, et les multiples filtres garantissent que les fonctionnalités qui survivent au processus ont été examinées sous tous les angles. Quand une fonctionnalité du C++ vous semble inutilement complexe ou bizarrement conçue, cherchez le paper correspondant : les "Alternatives Considered" et les "Design Rationale" expliquent presque toujours pourquoi les choix ont été faits. C'est souvent en lisant le paper qu'on passe de "c'est bizarre" à "c'est le meilleur compromis possible étant donné les contraintes".