En résumé : Lors d’un vote historique clos le 22 octobre 2026, les organismes nationaux de normalisation de l’ISO ont rejeté le brouillon final de la norme C++26. Au cœur de la controverse : l’intégration des contrats (P2900), vivement contestée par Bjarne Stroustrup et plusieurs éditeurs de compilateurs pour des motifs de sécurité et de maturité. Ce rejet met sous pression le calendrier de sortie de C++26 et pose la question du maintien des fonctionnalités phares comme la réflexion statique.
L’évolution du langage C++ traverse une crise inédite. Alors que la publication de la future norme C++26 semblait sur les rails, la décision des comités nationaux de normalisation vient bouleverser la feuille de route du standard ISO. Retour détaillé sur les causes de ce blocage, les divergences techniques autour de la programmation par contrat, et les scénarios de sortie de crise.
Le brouillon de C++26 rejeté par les organismes nationaux
Pour la première fois de l’histoire de C++, les organismes nationaux de normalisation ont rejeté le brouillon final d’une norme. En cause : les contrats, la grande nouveauté de C++26 censée offrir une solution language-level à la programmation orientée contrat, et définitivement enterrer la macro assert héritée du C. Le vote, clos le 22 octobre 2026, a recueilli 13 voix pour, 9 contre et 12 abstentions. C’est loin des deux tiers d’approbation et du maximum d’un quart de votes négatifs qu’exige l’ISO.
1. Les contrats, une vieille ambition de C++
Les contrats permettent d’écrire dans le code les conditions qu’une fonction attend et garantit. La proposition adoptée (P2900) en offre trois formes : un couple pre/post, représentant respectivement les préconditions et postconditions d’une fonction, placé à sa déclaration, et une assertion contract_assert dans son corps.
int racine(int x)
pre (x >= 0)
post (r : r >= 0);
Chaque contrat peut être ignoré, observé (la violation est signalée, l’exécution continue) ou appliqué (le programme s’arrête). Ce choix ne se fait pas dans le code mais à la compilation, généralement via une option. Un gestionnaire de violation global, remplaçable par l’application, centralise le traitement des erreurs.
L’idée est d’exposer les contrats à l’appelant, qui peut donc les vérifier au besoin, et les outils d’analyse peuvent y accéder sans entrer dans l’implémentation d’une fonction. Historiquement, ces contrats étaient indiqués dans des commentaires, par exemple sous la forme Doxygen /// @pre \p x >= 0, puis ajoutés dans le corps des fonctions, potentiellement avec assert, ce qui ajoutait un risque de divergence dans le temps entre les commentaires et le code.
De plus, les contrats offrent une solution toute trouvée pour le durcissement de la STL, par exemple en ajoutant pre(index < size()) à std::vector::operator[].
Cette idée n’est pas nouvelle pour le C++, une première proposition date de 2004, et une version des contrats avait déjà été adoptée pour C++20 avant d’être retirée in extremis en 2019. Le comité est reparti de zéro, avec un « produit minimal viable » destiné à être complété ensuite. Cette version a été adoptée en février 2025 par 100 voix contre 14, par le comité.
2. Un désaccord technique et procédural
Une minorité du comité, autour notamment de Bjarne Stroustrup et des équipes d’implementation des compilateurs de Microsoft et d’EDG, n’a jamais accepté cette conception. Faute d’obtenir gain de cause au sein du comité, elle s’est adressée directement aux organismes nationaux. Plusieurs d’entre eux, dont l’AFNOR pour la France, avaient d’ailleurs demandé le retrait des contrats dès 2025. Trois inquiétudes dominent.
2.1 Aucune garantie, et un défaut figé
Rien dans C++26 ne peut garantir l’inviolabilité d’un contrat depuis le code. Seule la compilation permet de manipuler leur niveau d’activation, un contrat ne peut donc pas être imposé. De plus, leur niveau d’activation manque de granularité : soit on les active tous, soit on les désactive tous. On ne peut pas définir des contrats obligatoires, puis des contrats vérifiés uniquement en mode debug par exemple.
Pire, une fonction inline compilée avec des réglages différents dans deux bibliothèques peut perdre son contrôle lors de la phase de link, sans que personne ne le sache.
Les « labels », prévus pour C++29 (P3400), corrigeraient une partie de ces points, en ajoutant une syntaxe pre, où label permet d’avoir une stratégie propre. Sauf que cela ne vaudrait que pour ceux qui les utilisent: la syntaxe courte, sans label, garderait son comportement actuel, faute de pouvoir le changer sans casser le code existant.
Les partisans répondent que les mêmes problèmes existent déjà avec assert, où il constitue même un comportement indéfini, et qu’un contrôle non exécuté n’est « pas pire que pas d’assertion du tout ». Cela pose des questions, car justement, quitte à ajouter une fonctionnalité au C++, l’objectif est de prendre l’expérience des solutions historiques et tenter de ne pas en reproduire les défauts.
2.2 Une maturité insuffisante
Les contrats sont implémentés dans GCC et Clang, mais les expériences de déploiement se sont limitées à contract_assert. Les préconditions et postconditions sur les déclarations, véritable nouveauté, n’ont pas été testées à grande échelle.
Cet argument est avancé par une partie des opposants aux contrats, mais pas tous. Il faut reconnaître que le manque de maturité est aussi un défaut de la réflexion statique et de std::execution, pourtant adoptés dans le standard aussi.
2.3 Le consensus contesté
On entre là dans le procédural. Quand tout se passe bien, une proposition avance par divers votes et sondages. Les membres du comité votent SF (strong favor), F (favor), N (neutral), A (against) ou SA (strong against). Si un membre vote A ou SA, il doit accompagner son vote d’un commentaire ou d’une question qui justifie son rejet. Par la suite, il est d’usage (mais pas obligatoire) que les auteurs de la proposition répondent aux questions, pour lever le doute ou pour corriger un défaut relevé.
Les opposants estiment que la conception a avancé à coups de votes, mais en ne répondant que rarement à leurs objections. L’ancien président du groupe d’étude, John Spicer, a même publié un mea culpa où il reconnaît avoir soutenu un rythme qui a exclu les objections de membres clés, dont les implémenteurs des compilateurs de Microsoft et EDG. Mais les partisans des contrats rappellent que chaque objection a été débattue lors de plusieurs réunions, et qu’une opposition, même persistante, n’est pas un droit de veto. En réalité, le sentiment est que les débats n’ont pas apporté de solutions aux objections, mais ont plutôt essayé de les minimiser.
Le débat ne recoupe pas parfaitement les camps. Andrzej Krzemieński, co-auteur de la proposition, admet que son modèle « n’est pas adopté par une partie importante » du comité, et juge « surprenant » que l’opposition de deux fournisseurs de compilateurs ne suffise pas à la disqualifier.
3. Et maintenant ?
La décision ne revient pas au comité C++ lui-même. C’est le président du sous-comité ISO concerné (SC22) qui tranchera, sur recommandation du comité, attendue à sa réunion de Búzios (Brésil) en novembre. Les règles ISO offrent quatre voies: un standard révisé soumis à un nouveau vote de huit semaines, un retour au stade du brouillon de comité (pour un nouveau vote après de lourdes modifications), une publication en technical-specification (C++26 ne serait plus un standard du langage, mais une possibilité d’implémentation), ou l’abandon. Faute d’approbation d’ici fin 2027, le projet sera annulé automatiquement.
Les partisans proposent de voter à nouveau sans toucher aux contrats, en comptant sur les réponses officielles du comité pour faire changer d’avis les pays opposants (car les refus des National Bodies sont aussi accompagnés de commentaires et de questions).
Mais ce pari est difficile, car même si les 12 pays abstentionnistes votaient tous « Oui », les 9 votes négatifs représenteraient encore plus de 25%. Il faudrait, en plus de convaincre tous les abstentionnistes, qu’au moins 4 pays changent de camp.
L’autre voie est de retirer les contrats pour publier le reste de C++26, et notamment la réflexion statique et std::execution, très attendues. Le retrait n’est pas trivial : il faut réécrire plusieurs parties de la norme et passer à nouveau devant les organismes nationaux. Il faudra aussi décorréler le durcissement de la bibliothèque standard des contrats. Il est largement déployé (notamment par Google qui a trouvé plus de mille bogues pour un surcoût de 0,3 % grâce à cela), mais pourrait être conservé, car sa première version était spécifiée sans contrat, et ses implémentations en sont déjà découplées.
Il existe un précédent de retrait de fonctionnalités sur menace de rejet définitif. En 2008, une proposition pour ajouter les concepts avait été retirée de C++0x (futur C++11). Ils sont revenus, mieux conçus, dans C++20. Ce retrait avait cependant eu lieu avant le premier vote des National Bodies.
Conclusion
Au-delà des contrats, ce vote pose une question de gouvernance. Pour les uns, il prouve que le contrôle extérieur prévu par l’ISO fonctionne quand un comité passe outre une opposition sérieuse. Pour les autres, il crée un précédent dangereux: une majorité au sein du comité peut être bloquée par une minorité ayant du poids aux National Bodies. La réunion de Búzios dira si le comité choisit le compromis, en sauvant C++26 sans les contrats, ou le bras de fer. Dans les deux cas, la leçon vaudra pour la suite: expliquer pourquoi l’on passe outre une objection compte autant que le décompte des voix.
Quel avenir pour la norme C++26 ?
Le rejet du brouillon de C++26 par les organismes nationaux marque un tournant historique dans l’évolution du langage. Loin d’un abandon pur et simple, ce vote sanctionne le passage en force d’une fonctionnalité majeure — les contrats (P2900) — contestée sur le plan technique par des figures clés comme Bjarne Stroustrup et les implémenteurs de compilateurs.
L’enjeu immédiat se reporte sur la réunion de Búzios et la décision du SC22 : le scénario le plus pragmatique reste le retrait des contrats afin de sécuriser la publication dans les délais des autres avancées très attendues, en particulier la réflexion statique et std::execution.
Pourquoi la norme C++26 a-t-elle été rejetée par l’ISO ?
Le brouillon final de la norme C++26 a été rejeté par les organismes nationaux de normalisation (13 voix pour, 9 contre, 12 abstentions, soit en dessous du seuil requis des deux tiers) en raison de l’intégration controversée des contrats (proposition P2900). Une minorité influente, menée notamment par le créateur du langage Bjarne Stroustrup et les équipes de compilateurs Microsoft et EDG, dénonce un manque de garanties à l’exécution, une granularité insuffisante et une maturité technique encore trop faible.
La sortie de C++26 est-elle définitivement annulée ?
Non. Le projet n’est pas abandonné. Le président du sous-comité ISO (SC22) doit trancher suite à la réunion de Búzios. Quatre issues restent possibles :
- Une révision rapide soumise à un nouveau vote de 8 semaines ;
- Un retour au stade de brouillon de comité pour une refonte plus lourde ;
- La publication sous forme de spécification technique (Technical Specification) sans valeur de standard officiel ;
- Le retrait pur et simple des contrats pour publier le reste de la norme dans les délais.
Qu’advient-il des autres nouveautés comme la réflexion statique et std::execution ?
Les fonctionnalités très attendues comme la réflexion statique et la bibliothèque de parallélisme std::execution ne sont pas remises en cause sur le fond. Si le comité décide de retirer les contrats pour débloquer l’approbation de C++26, ces nouveautés pourront être publiées dans le standard révisé, à condition que le travail de découplage éditorial soit réalisé à temps.
Qu’est-ce que les contrats en C++ et quel est le problème ?
Les contrats introduisent une syntaxe native de préconditions (pre), postconditions (post) et assertions (contract_assert) pour remplacer la macro historique assert. Les critiques portent sur le fait que leur activation dépend entièrement des options de compilation sans possibilité d’imposer un contrat obligatoire dans le code, avec des risques de perte de contrôle lors de la phase d’édition de liens (link) entre bibliothèques compilées différemment.
Annexes
La proposition
- P2900R14, Contracts for C++ : la spécification adoptée
- P2899R1, Contracts for C++ — Rationale : la justification et l’historique complet
- P3471R4, Standard library hardening
Les critiques
- P3573R0, Contract concerns (Stroustrup, Dos Reis, Vandevoorde, Spicer et al.)
- P3829R0, Contracts do not belong in the language
- P3835R0, Contracts make C++ less safe — full stop! : le mode mixte
- P3853R0, A thesis+antithesis=synthesis rumination on Contracts : le risque de figer le comportement par défaut
- P4238R1, Returning C++26 for the Evaluation It Skipped : l’argument procédural
- P4381R0, Chairing SG21 and then objecting to Contracts (Mea culpa de John Spicer)
Les défenses
- P3846R1, C++26 Contract Assertions, Reasserted : réponse objection par objection
- P4433R0, Do not remove Contracts from C++26
- P4388R0, Ship C++26
- P3850R1, A proposed plan for extending Contracts in C++29
- P3400R5, Controlling Contract-Assertion Properties : les labels
Entre les deux
- P4020R0, Concerns about contract assertions (Krzemieński, co-auteur de P2900)
