Pour moi, c’est une partie de l’explication seulement. C’est l’explication technique du crash.
Mais le vrai "bug", à mon avis, c’est qu’une telle erreur de programmation ne devrait pas avoir une telle conséquence. unwrap est au cœur de cet incident, mais n’est pas le cœur du problème.
Pour moi, le problème est organisationnel ou architectural en premier lieu.
D’abord, on pourrait imaginer des règles de programmations qui interdisent les unwrap, avec une vérification statique du code qui impose leur application. On peut imaginer qu’ils vont ajouter ce genre de vérification pour ce type d’erreur suite à l’incident. Ça, c’est une solution technique pour tuer une telle erreur dans l’œuf, mais ça ne fait pas tout.
On pourrait imaginer une revue attentive obligatoire pour augmenter les chances d’attraper plus d’erreurs, dont celles qui ne peuvent pas être remarquées par la vérification statique ou les tests automatiques. C’est une des solutions organisationnelles possibles.
Ça ne fait toujours pas tout, d’ailleurs j’imagine qu’ils ont déjà ça, or, l’erreur est passée quand-même. Dans tous les cas, il y aura toujours des erreurs de programmations qui passeront, tant que le code n’est pas vérifié formellement et exhaustivement (ce qui ne serait probablement pas réaliste, si c’est même possible).
Donc là, l’architecture de Cloudflare devrait être conçue pour être tolérante à ce genre de bugs, avec un déploiement progressif des évolutions du code ou des configurations. On peut supposer qu’il y a de la redondance chez Cloudflare, et qu’il serait possible de déployer la plupart des changements sur certains nœuds, et les choses continuent à fonctionner quand ils tombent en panne. Et on stoppe le déploiement si on constate des crashes à ce niveau.
Et toutes les solutions architecturales et organisationnelles pour limiter les erreurs humaines et sinon leurs conséquences.
C’est évidemment plus facile à dire qu’à faire. D’un autre côté, c’est spécifiquement le cœur de métier de Cloudflare. Et ce qui est un peu préoccupant, c’est qu’il n’est fait mention que des solutions techniques dans leur section Remediation and follow-up steps. C’est bien d’éviter le genre d’erreur qu’on vient de rencontrer à l’avenir, mais aucune amélioration du processus de déploiement n’est mentionnée, ou autre amélioration visant à gérer les erreurs de programmations ou autres erreurs humaines qui passent inévitablement les filtres. On peut espérer que c’est juste qu’ils ne communiquent pas là-dessus pour une raison qui m’échappe.
[^] # Re: « un vilain unwrap en Rust »
Posté par raphj (site web personnel) . En réponse au lien Cloudflare : incident du 18-nov post mortem (un vilain unwrap en Rust). Évalué à 7. Dernière modification le 19 novembre 2025 à 14:07.
Pour moi, c’est une partie de l’explication seulement. C’est l’explication technique du crash.
Mais le vrai "bug", à mon avis, c’est qu’une telle erreur de programmation ne devrait pas avoir une telle conséquence. unwrap est au cœur de cet incident, mais n’est pas le cœur du problème.
Pour moi, le problème est organisationnel ou architectural en premier lieu.
D’abord, on pourrait imaginer des règles de programmations qui interdisent les unwrap, avec une vérification statique du code qui impose leur application. On peut imaginer qu’ils vont ajouter ce genre de vérification pour ce type d’erreur suite à l’incident. Ça, c’est une solution technique pour tuer une telle erreur dans l’œuf, mais ça ne fait pas tout.
On pourrait imaginer une revue attentive obligatoire pour augmenter les chances d’attraper plus d’erreurs, dont celles qui ne peuvent pas être remarquées par la vérification statique ou les tests automatiques. C’est une des solutions organisationnelles possibles.
Ça ne fait toujours pas tout, d’ailleurs j’imagine qu’ils ont déjà ça, or, l’erreur est passée quand-même. Dans tous les cas, il y aura toujours des erreurs de programmations qui passeront, tant que le code n’est pas vérifié formellement et exhaustivement (ce qui ne serait probablement pas réaliste, si c’est même possible).
Donc là, l’architecture de Cloudflare devrait être conçue pour être tolérante à ce genre de bugs, avec un déploiement progressif des évolutions du code ou des configurations. On peut supposer qu’il y a de la redondance chez Cloudflare, et qu’il serait possible de déployer la plupart des changements sur certains nœuds, et les choses continuent à fonctionner quand ils tombent en panne. Et on stoppe le déploiement si on constate des crashes à ce niveau.
Et toutes les solutions architecturales et organisationnelles pour limiter les erreurs humaines et sinon leurs conséquences.
C’est évidemment plus facile à dire qu’à faire. D’un autre côté, c’est spécifiquement le cœur de métier de Cloudflare. Et ce qui est un peu préoccupant, c’est qu’il n’est fait mention que des solutions techniques dans leur section Remediation and follow-up steps. C’est bien d’éviter le genre d’erreur qu’on vient de rencontrer à l’avenir, mais aucune amélioration du processus de déploiement n’est mentionnée, ou autre amélioration visant à gérer les erreurs de programmations ou autres erreurs humaines qui passent inévitablement les filtres. On peut espérer que c’est juste qu’ils ne communiquent pas là-dessus pour une raison qui m’échappe.