C’est un événement sans précédent dans l’histoire du langage de Bjarne Stroustrup : le projet de norme C++26 a échoué à son vote d’approbation ISO. Le scrutin, clos le 13 octobre 2026, n’a recueilli que 60 % d’avis favorables alors que le seuil requis est de 66,67 %, neuf des vingt-deux pays votants s’étant prononcés contre, selon la synthèse documentée de Wikipédia sur C++26. Jamais un brouillon de norme C++ n’avait été retoqué à ce stade. Pour les équipes de développement comme pour les organismes de formation, la question est désormais : que va-t-il se passer, et faut-il revoir ses plans d’adoption ?
Plan de l'article
Un parcours qui semblait pourtant bouclé #
Sur le papier, C++26 avait franchi toutes les étapes dans les temps. Le brouillon était « feature complete » depuis la réunion de Sofia en juin 2025, les derniers commentaires avaient été traités à Kona en novembre 2025, et le comité WG21 avait officiellement expédié le texte le 28 mars 2026, à l’issue de la réunion de Londres, comme le raconte le compte rendu de la réunion ISO de mars 2026. Le vote technique interne avait d’ailleurs été très largement favorable.
Restait la dernière marche : le vote DIS (Draft International Standard), par lequel les organismes nationaux de normalisation approuvent formellement la publication. C’est cette marche-là que C++26 vient de manquer. La nuance est importante pour bien lire la situation : le travail technique du comité est terminé et validé ; c’est l’approbation formelle des pays membres de l’ISO qui fait défaut.
À lire Node.js 27 alpha : une seule version majeure par an, et toutes deviennent LTS
Les « contracts », pomme de discorde #
Au cœur du blocage, on retrouve la fonctionnalité la plus discutée de cette version : les contrats (« contracts »). Ce mécanisme permet d’exprimer directement dans le code des préconditions, postconditions et assertions, vérifiables à l’exécution. Une avancée attendue de longue date pour la robustesse des programmes, mais dont les détails — sémantique d’évaluation, interactions avec le reste du langage, implications pour la sûreté — ont divisé le comité jusqu’au bout.
Le rejet du vote ISO semble directement lié à leur inclusion. Dans la foulée, un document officiel du comité, publié fin octobre et intitulé « Do not remove Contracts from C++26 », plaide pour leur maintien dans la norme — signe que l’option inverse, les retirer pour débloquer la publication, est ouvertement sur la table (le texte est consultable sur le site du groupe de travail WG21).
Deux scénarios possibles
Le comité doit maintenant trancher entre deux voies. La première : amender le texte, par exemple en retirant ou en remaniant les contrats, puis soumettre le brouillon à un nouveau vote. La seconde : défendre le texte en l’état et tenter de convaincre les délégations nationales réticentes. Dans les deux cas, le calendrier de publication glisse, et la discussion se poursuivra lors des prochaines réunions plénières du comité cet automne et cet hiver.
Ce que ça change concrètement pour les développeurs #
Faut-il s’inquiéter si l’on code en C++ au quotidien ? Pas dans l’immédiat. Les compilateurs majeurs (GCC, Clang, MSVC) implémentent les fonctionnalités de C++26 au fil de l’eau, en se basant sur le brouillon technique — et celui-ci ne change pas tant que le comité n’a pas statué. Les nouveautés déjà intégrées dans vos chaînes de compilation ne vont pas disparaître du jour au lendemain.
À lire Gemini 4 Carbon : Google réserve son modèle le plus puissant à la cyberdéfense
En revanche, deux précautions s’imposent. D’abord, éviter de bâtir dès aujourd’hui du code de production sur les contrats : c’est précisément la partie du texte susceptible d’être retirée ou modifiée avant publication. Ensuite, surveiller la communication officielle du comité avant de figer un référentiel interne « C++26 » dans vos guides de style ou vos plans de formation : tant que la norme n’est pas publiée par l’ISO, son contenu exact reste révisable.
Un signal à ne pas sous-estimer pour les équipes
Au-delà de la mécanique de normalisation, cet épisode illustre une tension de fond : C++ cherche à répondre à la pression croissante sur la sûreté mémoire et la fiabilité — pression venue autant des régulateurs que de la concurrence de langages comme Rust — tout en préservant sa compatibilité et sa diversité d’implémentations. Les contrats sont justement l’une des réponses du langage sur ce terrain. Que leur inclusion fasse achopper le vote final montre à quel point le sujet est devenu stratégique.
Pour les responsables techniques, c’est l’occasion de rappeler une bonne pratique : on ne planifie pas une migration de version de langage sur des annonces, mais sur des textes publiés et des implémentations vérifiées. Les trois dernières normes (C++17, C++20, C++23) avaient passé l’étape ISO sans accroc, ce qui avait installé un sentiment de routine. C++26 vient de rappeler que la publication d’une norme internationale reste un processus politique autant que technique.
Et maintenant ? #
Le cycle de trois ans qui rythme les sorties de C++ depuis 2011 n’est pas remis en cause sur le fond : le comité a déjà commencé à engranger des travaux pour la version suivante. Mais pour C++26, la date de publication effective dépend désormais de la vitesse à laquelle un consensus se dégagera sur les contrats. Si le comité choisit de les retirer, un nouveau vote pourrait intervenir rapidement ; s’il choisit de les défendre, la discussion avec les organismes nationaux pourrait durer davantage.
À lire Bun 1.4.4 intègre un formateur compatible Prettier et une vérification de types
Pour qui se forme au C++ moderne, le conseil reste inchangé : consolider C++20 et C++23, qui sont stables, publiés et largement supportés, et suivre C++26 comme un horizon proche — mais pas encore comme un acquis.
