Danlord : Débugger, c'est enquêter dans un roman policier dont on a soi-même écrit le scénario, en ayant oublié l'identité du coupable.
Développement
Le 23 octobre 2026, les organismes nationaux de normalisation ont rejeté le projet final de C++26. C'est la première fois en près de trente ans de normalisation qu'un standard C++ échoue à ce stade. En cause : les « contrats », une fonctionnalité attendue depuis des années, qui a fini par diviser le comité au point de bloquer toute la nouvelle version du langage : réflexion à la compilation et std::execution compris.
Ce vote devait être une formalité. Il est devenu une crise de gouvernance. Voici ce qui s'est passé, pourquoi, et ce que cela change pour les développeurs.
Mise à jour du 11 novembre 2026. Aucune décision n'a encore été prise sur l'avenir de C++26. Le comité WG21 se réunit à Búzios (Brésil) du 16 au 21 novembre pour tenter de sortir de l'impasse. Les commentaires officiels des pays doivent être publiés au plus tard mi-janvier 2027. En attendant, la norme en vigueur reste C++23.
Cet encadré sera complété à l'issue de la réunion de Búzios.
Le scrutin DIS (Draft International Standard) sur C++26 a duré douze semaines et s'est clos le 23 octobre 2026. Le lendemain, Robert Seacord, responsable du comité C à l'ISO, a annoncé sur LinkedIn que le vote était terminé et que le projet avait été désapprouvé.
Pour passer, un DIS doit remplir deux conditions à la fois. C++26 n'en a rempli aucune :
Condition | Seuil exigé | Résultat obtenu |
|---|---|---|
Votes « pour » parmi les membres votants (P-members) | au moins 2/3, soit 14 voix | 12 sur 20 (60 %) |
Votes « contre » parmi tous les pays votants | au plus 25 %, soit 5 voix | 9 sur 22 (41 %) |
Neuf pays ont voté contre, tous avec des commentaires techniques : Danemark, Espagne, Finlande, Iran, Italie, Japon, Luxembourg, Roumanie et Suède. La France et l'Irlande se sont abstenues en envoyant tout de même des commentaires ; la Pologne et les États-Unis se sont aussi abstenus. Les commentaires détaillés ne sont pas encore publics : l'ISO dispose de douze semaines pour publier le rapport complet, soit au plus tard mi-janvier 2027.
Le contraste avec les étapes précédentes est frappant. En mars 2026, à la réunion de Londres-Croydon, le comité C++ (WG21) avait adopté le projet par 114 voix pour, 12 contre et 3 abstentions. Selon Daveed Vandevoorde, du groupe de direction du comité, aucun projet C++ antérieur n'avait jamais reçu une seule voix contre au stade DIS.
Le seul précédent connu est lointain : en 2006, le DIS 26926 consacré à C++/CLI (l'extension .NET de Microsoft) avait échoué au même vote. Le projet avait ensuite été purement et simplement abandonné.
C++ n'appartient à aucune entreprise : il est défini par la norme ISO/IEC 14882, rédigée par le groupe de travail WG21 (rattaché au sous-comité SC22 de l'ISO/IEC JTC1). Une nouvelle version suit un parcours en plusieurs étapes :
Propositions (papers) : chaque fonctionnalité est défendue par écrit, discutée dans les sous-groupes (évolution du langage, bibliothèque, etc.) puis votée en séance plénière.
CD (Committee Draft) : le projet complet est soumis aux pays pour commentaires. Pour C++26, cette phase s'est close en octobre 2025 et a produit 411 commentaires nationaux.
Résolution des commentaires : WG21 traite les commentaires et fige le texte. C'est ce qui a été fait en mars 2026 à Londres-Croydon, où Herb Sutter a pu annoncer que le travail technique sur C++26 était terminé.
DIS (Draft International Standard) : les organismes nationaux votent pour ou contre le projet dans son ensemble : on ne vote pas fonctionnalité par fonctionnalité.
Publication : après relecture éditoriale finale, l'ISO publie la norme.
Jusqu'ici, une règle tacite faisait fonctionner l'ensemble : un pays ne votait « non » au DIS que si une information nouvelle ou une erreur de procédure apparaissait. Les débats techniques étaient censés être tranchés en amont, au sein de WG21. Le 23 octobre, cette règle a volé en éclats.
Les contrats (proposition P2900) permettent d'écrire, directement dans la signature d'une fonction, ce qui doit être vrai avant et après son appel. Une image, puis un exemple.
Pour les non-développeurs : imaginez la notice d'un appareil électrique qui indique « brancher uniquement sur du 220 V ». Un contrat, c'est cette consigne écrite dans le code lui-même, et que la machine peut vérifier toute seule à chaque utilisation. Pour les développeurs, voici à quoi cela ressemble :
#include <vector>
class Compte {
double solde_ = 0.0;
public:
// Précondition : le montant retiré est positif et couvert par le solde
// Postcondition : le solde reste positif ou nul
void retirer(double montant)
pre(montant > 0.0)
pre(montant <= solde_)
post(solde_ >= 0.0)
{
solde_ -= montant;
}
// Postcondition nommée sur la valeur de retour
double solde() const
post(r: r >= 0.0)
{
return solde_;
}
};
int moyenne(const std::vector<int>& notes) {
contract_assert(!notes.empty()); // vérification dans le corps
int total = 0;
for (int n : notes) total += n;
return total / static_cast<int>(notes.size());
}pre(...) exprime une précondition ;
post(...) une postcondition, éventuellement sur la valeur retournée (r) ;
contract_assert(...) une assertion à l'intérieur du corps, appelée à remplacer la vieille macro assert.
Sur le papier, presque tout le monde adhère : c'est de la documentation que le compilateur comprend et qui ne peut pas « vieillir » en silence comme un commentaire. Les concepts de C++20 contraignent les types acceptés à la compilation ; les contrats feraient la même chose pour les valeurs, à l'exécution.
Le problème est dans les détails. Le code ne décide pas si un contrat est vérifié ni de ce qui se passe en cas d'échec. La norme définit quatre sémantiques (ignore, observe, enforce et quick-enforce) et laisse le choix à l'implémentation. Dans GCC 16, on la choisit par une option de compilation. Le même code peut donc, selon la configuration de build, arrêter le programme, journaliser l'erreur et continuer, ou ne rien vérifier du tout.
Ce n'est pas le premier échec des contrats. Une première version avait été intégrée à C++20 lors de la réunion de Cologne en 2019, puis retirée lors de la même réunion. Un groupe d'étude dédié (SG21) a ensuite travaillé de 2020 à 2024 environ sur une nouvelle conception, transmise au groupe d'évolution du langage (EWG), qui l'a finalement intégrée à C++26 par un vote majoritaire.
Les commentaires officiels ne sont pas encore publiés, mais tous les signaux convergent vers les contrats. Les deux objections soulevées lors de la plénière de mars portaient sur eux, plusieurs pays avaient déjà demandé leur retrait lors de la phase CD, et un document, P4238, appelait explicitement les organismes nationaux à voter non.
Une garantie qui peut disparaître. Puisque la sémantique est choisie au build, une même précondition peut être vérifiée dans une configuration et ignorée dans une autre. Pour beaucoup, une vérification que l'on peut désactiver n'est pas une garantie sur laquelle un programme peut s'appuyer.
Des prédicats risqués. Les débats portent aussi sur ce qui peut mal tourner à l'intérieur même d'une condition (effets de bord, comportement indéfini).
Trop peu d'expérience en production. Les opposants estiment que la fonctionnalité n'a pas été suffisamment éprouvée sur du code réel avant d'être figée dans une norme.
Un problème de procédure. P4238, porté notamment par la C++ Alliance et cosigné par J. Daniel García, soutient que les contrats sont entrés dans C++26 par des manœuvres de procédure qui n'enfreignaient aucune règle, mais sans jamais réconcilier les objections persistantes. Le vote DIS y est présenté comme le dernier contre-pouvoir disponible.
Des années de travail et plusieurs votes majoritaires. La conception actuelle a été adoptée à plusieurs reprises, chaque fois avec une large majorité.
Pas d'information nouvelle. Andreas Fertig, qui représente l'Allemagne au comité, juge qu'un nouveau document reprenant d'anciens arguments ne constitue pas une information nouvelle justifiant un rejet.
Un pacte de confiance rompu. Pour lui, chaque norme ISO est un ensemble de compromis : chacun perd parfois, et cette fois les perdants ont refusé d'accepter leur défaite. Il qualifie le résultat de « désastre massif » pour la communauté.
Au-delà de la technique, ce vote pose donc une question de gouvernance : jusqu'où un pays peut-il rejouer au DIS un débat déjà tranché par le comité ?
Le vote DIS porte sur le document entier. En rejetant le projet, les pays n'ont pas seulement bloqué les contrats : ils ont gelé toutes les nouveautés de C++26, dont plusieurs étaient parmi les plus attendues de la décennie.
Fonctionnalité | Ce qu'elle apporte |
|---|---|
Réflexion à la compilation | Le programme peut inspecter ses propres types, membres et énumérations à la compilation. Fin d'une bonne partie des macros et des générateurs de code externes (sérialisation, ORM, bindings). |
| Un modèle standard pour la programmation asynchrone et parallèle, avec ordonnanceurs et composition de tâches. |
Durcissement de la bibliothèque standard (library hardening) | Des vérifications de bornes et de préconditions dans la bibliothèque standard pour réduire les failles mémoire. Il s'appuie en partie sur les contrats. |
Ce dernier point complique tout : retirer les contrats impose de revoir aussi le durcissement de la bibliothèque, l'un des chantiers phares de C++26 en matière de sécurité mémoire, un sujet sur lequel C++ est sous forte pression face à Rust.
Les règles de l'ISO prévoient quatre issues après un DIS rejeté. Toutes impliquent un retard, et toutes doivent être approuvées par une majorité au sein de WG21.
Le dilemme est là : WG21 a envoyé C++26 avec les contrats au vote, à plus des deux tiers. Il est difficile d'imaginer ce groupe renoncer au travail de plusieurs années. Mais il est tout aussi difficile d'imaginer les pays opposants changer leur vote si les contrats restent. Même l'abandon pur et simple (qui ramènerait à C++23 et obligerait à réintégrer une à une les nouveautés dans C++29) exige une majorité.
Le comité se réunit à Búzios, au Brésil, du 16 au 21 novembre 2026, avec un objectif prioritaire : sortir de l'impasse. Trois lignes s'affrontent :
Retirer les contrats pour publier le reste au plus vite. C'est la position de J. Daniel García (coauteur de P4238), pour qui le reste de la norme serait alors très probablement approuvé. Daveed Vandevoorde recommande lui aussi leur retrait, avec des ajustements pour préserver le durcissement de la bibliothèque.
Revoter sans rien changer. C'est ce que propose le document P4433R0, signé par seize partisans des contrats. Ils estiment que retirer la fonctionnalité ne serait pas rapide : c'est un changement lourd, qui obligerait à repenser le durcissement de la bibliothèque.
Déplacer les contrats vers une spécification technique ou un document séparé, comme l'ont demandé certains pays.
Même le nom est en suspens. Si la norme est publiée en 2027, Vandevoorde estime que « C++27 » aurait du sens. Ce ne serait pas inédit : C++23 a été publié si tard qu'il porte officiellement la référence ISO/IEC 14882:2024.
L'impasse pèse aussi sur la suite : tant que le sort de C++26 n'est pas réglé, les travaux sur C++29 sont eux aussi à l'arrêt.
À court terme, rien ne casse. Les compilateurs implémentent le projet de travail du comité, et le vote ne change pas ce qu'ils livrent déjà.
La norme officielle reste C++23. C'est la seule version publiée et stable aujourd'hui.
GCC 16 accepte -std=c++26 et implémente les contrats dans son support expérimental.
Clang propose -std=c++2c, mais son implémentation des contrats n'a pas encore été fusionnée.
Le code qui utilise déjà des fonctionnalités C++26 n'a rien à défaire pour l'instant. Mais il faut garder en tête qu'il s'appuie sur un brouillon, pas sur une norme.
Le conseil le plus prudent concerne les contrats eux-mêmes : si vous écrivez déjà pre, post ou contract_assert avec GCC 16, vous dépendez précisément de la partie contestée. Leur syntaxe ou leur sémantique pourrait changer, voire disparaître de la prochaine norme. Pour du code de production, mieux vaut s'en tenir pour l'instant à assert ou à vos propres macros de vérification.
Pour la réflexion et std::execution, le risque est plus faible : elles ne sont pas au cœur du litige. La question est surtout quand elles deviendront officielles.
L'échec de C++26 n'est pas la fin de C++. C'est le signe que le processus de normalisation, fondé depuis 1998 sur la confiance et le consensus, atteint ses limites quand un langage doit concilier des besoins opposés.
Pour certains utilisateurs (systèmes embarqués, finance, jeux vidéo), une vérification doit pouvoir être supprimée sans aucun coût. Pour d'autres (sécurité, systèmes critiques), une vérification qu'on peut supprimer n'est pas une garantie. Ajouter quelque chose d'aussi simple en apparence que « vérifier que l'argument est positif » à un langage chargé de quarante ans de code, de plusieurs compilateurs et de millions d'utilisateurs s'avère d'une difficulté redoutable.
Le vote prouve aussi que les organismes nationaux ne sont pas de simples chambres d'enregistrement. Que l'on y voie un sursaut de rigueur ou une rupture du pacte de confiance, il oblige WG21 à se poser une question qu'il évitait : comment trancher un désaccord profond sans laisser une minorité bloquer tout le monde, ni une majorité ignorer des objections persistantes ?
La réponse se dessinera à Búzios. D'ici là, une chose est sûre : la prochaine norme C++ arrivera en retard, et s'appellera peut-être C++27.
Andreas Fertig, C++26 DIS failed, how does C++ survive?, 3 novembre 2026
Antonio Cortés, C++26 fails its ISO ballot, and contracts are the reason, 26 octobre 2026 (d'après l'analyse de Mateusz Pusz, The result of the C++26 DIS ballot)
Developpez.com, Le projet C++26 a échoué au vote de l'ISO
Herb Sutter, C++26 is done! Trip report, mars 2026
WG21, P4238R0 (C++ Alliance)
Reticle Signal, C++26 failed its ballot over contracts
Wikipedia, C++26
Commentaires (0)