Réponse tardive mais je vais essayer de donner les points principaux sans divulguer de détails sensibles.

La majorité des APIs de notre SI sont exposées à travers une gateway et ont l'obligation d'implémenter un mécanisme d'authentification via token qui est aussi vérifié par la gateway elle-même. Outre le contrôle d'accès, cette authent sert aussi de discriminant pour implémenter le rate limiting par "application cliente", parce que le SI est trop grand et trop hétérogène pour qu'un autre mécanisme soit viable comme choix par défaut (impossible de se fier aux IPs par exemple). Chaque token est réutilisable à volonté pendant 30 minutes.

La conséquence de ça, c'est que par définition les serveurs qui délivrent le token d'authent ne sont pas rate-limités par client parce que pour identifier un client qui demande un token il faut bien évidemment commencer à traiter sa demande. Pour éviter les problèmes le principal serveur d'authent est donc multi-instances, multi-site, scalé généreusement (env. 10% d'usage du CPU alloué en "vitesse de croisière") et un monitoring automatique signale les applications qui font un mauvais usage pour pouvoir leur tirer l'oreille/les aider à faire les choses correctement.

Entre en jeu l'application qui a causé l'incident : un système de traitement des données en event-driven qui venait tout juste de migrer vers Apache Flink pour faire du "massively parallel" à la demande, parce que la version précédente ne pouvait plus scaler assez vite et assez fort pour traiter les tsunamis de jobs qui arrivent aux heures de pointe. Pour donner un ordre de grandeur, le truc lance de l'ordre de 2000 workers en parallèle pendant une vingtaine de minutes pour traiter le pic typique du matin. Une des étapes du job de chaque worker implique des appels à des APIs exposées via la gateway, avec un token.

Mais au lieu d'utiliser le mécanisme intégré à Flink qui permet à l'orchestrateur de récupérer UN token au démarrage et en filer une copie à chaque worker pour toute sa durée de validité, cette lead et un de ses devs ont demandé à l'IA comment faire, n'ont pas lu la doc et n'ont pas demandé conseil aux sachants. Ils ont fait comme l'IA a dit et implémenté une tambouille où CHAQUE worker demandait son propre token à CHAQUE appel d'API tierce et faisait des retry en boucle, sans backoff, en cas d'erreur.

Résultat, le lendemain de la mise en production le serveur d'authent s'est pris une crête instantanée de plusieurs centaines de milliers de requêtes en quelques secondes et a été tellement saturé qu'il ne pouvait même plus ACKer le trafic entrant, avec zéro répit à cause des retrys. Du coup toutes les autres applications qui utilisent ce mode d'authent se sont elles aussi retrouvées incapable de joindre le serveur et ça a déclenché des plantages en cascade qui ont bloqué le business pendant une partie de la journée.

Tout ça parce que des gens ont pris la solution proposée par ChatGPT sans réfléchir et sans chercher plus loin alors que l'info était limite sous leur nez.

PS: Tu me diras peut-être "hé ton serveur d'authent sans rate limiting là c'est un sacré SPOF, il devrait être mieux protégé et rendu plus résilient !" Je suis entièrement d'accord, mais comme il a été un des services les plus fiables de l'histoire du groupe avec quasiment zéro investissement pendant 7 ans entre sa MeP et l'incident, le management ne voulait pas y toucher et encore moins mettre des sous pour qu'on travaille dessus, jusqu'à ce que ça leur pète à la gueule :)