Vous vous souvenez quand ChatGPT tombait trop souvent en rade et que ça vous faisait juste lever les yeux au ciel avant d'aller vous chercher un café en trainant de la pantoufle ??

Bah cette époque est en train de se terminer mes amis.

Les analystes d'Ookla viennent d'éplucher 471 jours de données Downdetector aux États-Unis, ce qui représente environ 3,7 millions de signalements sur les grandes plateformes IA (ChatGPT, Claude, Gemini, Copilot) + les deux géants du cloud qui les font tourner, AWS et Azure et le constat est sans appel : Du côté des applis IA, les grosses journées de panne ont été multipliées par 8 en un an. Y'en a eu 6 au premier trimestre 2025, et 51 sur le même trimestre en 2026.

Et le truc qui a changé entre l'année dernière et aujourd'hui, c'est que l'IA n'est plus un gadget optionnel. Vous l'avez branchée dans votre code, vos analyses, votre support client, vos petits automatismes du quotidien... Du coup une session qui se coupe ou une tâche d'agent qui se fige, bah ça pète du vrai boulot qui tourne à l'intérieur de vrais process métier.

Et à mon grand désarroi, le mauvais élève, c'est Claude puisqu'il concentre à lui seul 39 de ces 51 journées noires, là où Gemini en compte 7, Copilot 3 et ChatGPT 2.

Toutefois, ce chiffre est à prendre avec un peu de nuance car début 2025, Claude ne générait quasiment aucun signalement sur Downdetector, pour la simple et bonne raison que peu de gens l'utilisaient. Puis l'usage a décollé (Claude Code en tête, avec un chiffre d'affaires annualisé d'Anthropic qui bondit de 14 à 47 milliards de dollars entre février et mai), et les pannes avec.

Rien que durant le mois de mars 2026, Claude a totalisé presque 3 fois plus de signalements qu'en février. Ce n'est pas forcément qu'il est devenu moins fiable, mais c'est juste qu'il joue maintenant dans une autre cour, avec beaucoup (pardon : BEAUCOUP) plus de monde qui tape trèèèès fort dessus.

À l'inverse, ChatGPT a vu sa médiane mensuelle d'erreurs baisser entre avril 2025 et avril 2026, alors même que l'usage de Codex partait dans la stratosphère sur la même période. Plus d'utilisateurs et pourtant moins de bruit de fond, ça veut dire qu'OpenAI a sérieusement bossé la tuyauterie pour proposer un service fiable.

Mais quand une de ces plateformes tombe, ça ne veut pas forcément dire que la panne vient du modèle lui-même. En fait le problème se loge très souvent dans la couche produit que vous voyez (login, routage, gestion de la charge, files d'attente), mais également dans le cloud qui héberge tout ce petit monde, ou dans la couche d'accès (DNS, passerelles web, authentification). Bref, votre prompt qui refuse de répondre, ça peut en réalité cacher 10 causes complètement différentes.

L'exemple le plus parlant, c'est la grosse panne d'AWS du 20 octobre 2025 , où le système de gestion DNS est parti en toupie durant une grande partie de la journée, provoquant de nombreuses coupures dans tout un tas de services. Et 9 jours plus tard, c'était au tour d'Azure de planter. Ce ne sont pas des services IA à proprement dit mais comme ils en hébergent aussi, et bien ça se répercute sur les services.

Et c'est ça tout le piège dans lequel on s'est confortablement installé car derrière nos Claude Code, nos ChatGPT et compagnie, se cache des services essentiels détenus par une poignée de boîtes. La prochaine grosse coupure de Claude ou de ChatGPT pourrait débuter à cause d'un pauvre GPU qui lâche, d'une mauvaise config poussée en production un vendredi soir, d'un DNS qui déraille ou encore d'une simple règle de quotas foireuse.

Et côté utilisateur lambda, il n'y a malheureusement pas grand-chose à faire à part patienter en gardant un œil sur les pages de statut des services ( status.anthropic.com , status.openai.com et compagnie) pour savoir si ça vient de vous ou d'eux.

Maintenant, je pense que si vous montez des workflows sérieux à base d'agents sur ces outils, la bonne question n'est pas de savoir si le service est en ligne. C'est plutôt de savoir quelles parties de votre boulot dépendent de quelle couche, et de ce qui va vraiment se passer le jour où l'une d'elles va se mettre à tousser sérieusement. C'est ce que les équipes IT ont appris à la dure récemment avec les grosses pannes Microsoft 365 , sauf qu'ici la dépendance est encore plus profonde.

Source

Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !

Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.

Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.

Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :

grep -l "AdministratorAccess" */global/iam/users/*/policies.json

diff prod/global/iam/roles/api/info.json staging/global/iam/roles/api/info.json

go install github.com/semonte/sisu@latest

Aujourd’hui on va parler d’un outil de ouf pour trouver des buckets S3 ouverts : FestIn !

C’est le genre d’outil dont raffolent les chercheurs en sécurité puisqu’il qui explore tous les recoins du web pour dénicher des trucs que vous n’auriez jamais trouvé.

FestIn c’est la grosse artillerie de l’énumération de buckets S3 puisqu’il a tellement d’options que les autres outils à côté c’est de la gnognotte. Attention, c’est bien sûr à utiliser uniquement sur vos propres noms de domaines ou dans le cadre de missions d’audit pour lesquelles vous avez toutes les autorisations.

Avec lui, vous allez pouvoir :

• Utiliser différentes techniques pour trouver des buckets : crawling du DNS et des pages web, analyse des réponses S3
• Faire vos requêtes en passant par un proxy, no stress 🕶
• Vous passer des credentials AWS, puisque ça marche avec n’importe quel provider compatible S3
• Configurer vos propres serveurs DNS, parce que vous êtes trop beau gosse.
• Profiter d’un crawler HTTP de compétition qui va retourner le web pour vous
• Faire des recherches récursives et avoir du feedback entre les différents modules pour un max d’efficacité
• Faire tourner le schmilblick en mode « watch » pour choper les nouveaux domaines en temps réel, ce qui est assez ouf quand on y pense.
• Sauvegarder tous les domaines découverts dans un fichier, pour faire joujou avec plus tard
• Indexer direct le contenu des objets des buckets pour faire des recherches full text de la mort, mieux que Google ! 😎
• Cibler votre recherche sur des domaines spécifiques si vous voulez pas vous éparpiller

Pour l’installer c’est fastoche, au choix :

pip install festin

Ou en mode Docker :

docker run --rm -it cr0hn/festin -h

C’est du brut, du bourrin, puisqu’on va envoyer des requêtes en masse et gratter un max d’infos. Attention cependant, on reste fair-play, on ne veut pas faire planter le serveur non plus.

Par défaut, FestIn prend un unique domaine en argument :

festin mon-super-site.com

Mais on peut aussi lui filer un fichier texte contenant une liste de domaines, histoire d’être plus productif :

1. Crée un fichier domaines.txt avec tes domaines, un par ligne.
2. Lance la commande :

cat domaines.txt | festin -f -

FestIn balance plusieurs tests en même temps pour aller plus vite. Par défaut, il en lance 5. Si vous êtes pressé et que votre machine encaisse, vous pouvez augmenter ce nombre avec l’option -c :

festin -c 10 mon-super-site.com

Attention cependant, ne balancez pas un truc de fou, ça risque de faire bugger le site ciblé. On est là pour glaner des infos, pas pour casser du serveur.

L’outil dispose également d’un petit bot intégré qui va scanner le site à la recherche de liens pouvant mener à des buckets S3. On peut le configurer avec plusieurs options :

• Timeout (-T ou –http-timeout) : Si le site est lent, on augmente le timeout pour pas que le scan plante. Par défaut, c’est 5 secondes.
• Récursion max (-H ou –http-max-recursion) : On limite la profondeur du scan pour éviter de partir en vadrouille sur tout le net. Par défaut, c’est 3 niveaux, genre site.com -> lien -> site2.com -> lien -> site3.com.
• Limite de domaine (-dr ou –domain-regex) : On peut dire au robot de se focaliser uniquement sur les sous-domaines qui correspondent à une expression régulière.
• Liste noire (-B) : Fich un fichier texte contenant des mots clés. Si un domaine contient un de ces mots, on l’ignore.
• Liste blanche (-W) : Même principe, mais à l’envers. On scanne uniquement les domaines contenant des mots clés de la liste blanche.

Pour cela, vous devez créer un fichier blacklist.txt contenant « cdn » et « photos » (on ignore les liens vers des CDN et des images) puis lancer la commande :

festin -T 20 -M 8 -B blacklist.txt -dr .mondomaine\.com mon-super-site.com

Attention : l’option -dr attend une expression régulière valide au format POSIX. Par exemple, mondomaine.com est invalide, alors que \.mondomaine\.com est correct.

FestIn crache un paquet d’infos intéressantes, pas seulement sur les buckets S3, mais aussi sur d’autres éléments identifiés. Ces infos peuvent ensuite être utilisées avec d’autres outils comme nmap.

Pour récupérer les résultats, FestIn propose trois modes qu’on peut combiner :

• Fichier de résultats FestIn (-rr ou –result-file) : Ce fichier contient une ligne JSON par bucket trouvé, avec le nom de domaine d’origine, le nom du bucket et la liste des objets qu’il contient.
• Fichier de domaines découverts filtrés (-rd ou –discovered-domains) : Celui-là liste un domaine par ligne. Ce sont des domaines trouvés par le crawler, le DNS ou les tests S3, mais qui ont été filtrés selon les options définies.
• Fichier brut de tous les domaines découverts (-ra ou –raw-discovered-domains) : Comme son nom l’indique, c’est la liste brute de tous les domaines identifiés par FestIn, sans aucun filtre. Idéal pour du post-traitement et de l’analyse.

récupérer les résultats dans trois fichiers distincts et enchaîner avec nmap :

festin -rr festin.results -rd domaines_filtres.txt -ra domaines_bruts.txt mon-super-site.com

festin -rd domaines_filtres.txt && nmap -Pn -A -iL domaines_filtres.txt -oN nmap-resultats.txt

FestIn peut utiliser Tor pour plus de discrétion. Il faut juste avoir un proxy Tor lancé en local sur le port 9050 (configuration par défaut). Activez-le avec l’option --tor :

tor & festin --tor mon-super-site.com

Et il peut aussi effectuer des recherches DNS. Voici les options dispo :

• Désactiver la découverte DNS (-dn ou –no-dnsdiscover) : Si on a pas besoin de ce type de recherche.
• Serveur DNS personnalisé (-ds ou –dns-resolver) : Pratique si on veut utiliser un serveur DNS différent de celui par défaut.

Comme ceci :

festin -ds 8.8.8.8 mon-super-site.com

Ce script ne se contente pas de dénicher les buckets S3 ouverts, il peut aussi télécharger leur contenu et l’indexer dans un moteur de recherche plein texte. Ça permet ensuite de lancer des recherches directement sur le contenu des buckets ! Pour activer l’indexation, FestIn utilise Redis Search, un projet Open Source.

Il faut deux options :

• Activer l’indexation (–index) : Indispensable pour que le contenu soit stocké dans le moteur de recherche.
• Configuration du serveur Redis Search (–index-server) : Uniquement si votre serveur Redis Search est sur une IP/port différent de localhost:6379 par défaut.

Lancez d’abord Redis Search en tâche de fond :

docker run --rm -p 6700:6379 redislabs/redisearch:latest -d

Puis lancez FestIn avec l’indexation et le serveur distant :

festin --index --index-server redis://127.0.0.1:6700 mon-super-site.com

Attention : l’option --index-server doit obligatoirement commencer par le préfixe redis://.

Bien sûr, on a pas forcément envie de relancer FestIn à chaque nouveau domaine à analyser. C’est pour ça qu’il existe le mode surveillance. FestIn se lance et attend l’ajout de nouveaux domaines dans un fichier qu’il surveille. Pratique pour l’utiliser avec d’autres outils comme dnsrecon.

Lancez FestIn en mode surveillance avec le fichier domaines.txt :

festin --watch -f domaines.txt

Dans un autre terminal, ajoutez des domaines à domaines.txt :

echo "encore-un-autre-site.com" >> domaines.txt

Dès qu’un nouveau domaine est ajouté au fichier, FestIn le scanne automatiquement à la recherche de buckets S3 ouverts. Pour aller plus loin, on peut combiner FestIn avec un outil de reconnaissance DNS comme DnsRecon. L’idée est de récupérer des sous-domaines potentiels liés au domaine principal et de les balancer ensuite à FestIn pour scanner d’éventuels buckets S3 cachés.

Etape 1 : Scruter le domaine cible avec DnsRecon

On va utiliser DnsRecon pour trouver des sous-domaines associés à cible.com. Sauvegardez la sortie dans un fichier CSV :

dnsrecon -d cible.com -t crt -c cible.com.csv

Etape 2 : Préparer le fichier pour FestIn

On isole les sous-domaines du fichier CSV pour les injecter dans FestIn (un domaine par ligne) :

tail -n +2 cible.com.csv | sort -u | cut -d "," -f 2 >> cible.com.domaines

Etape 3 : Lancer FestIn et récupérer les résultats

On balance le fichier de sous-domaines à FestIn en activant la recherche Tor, la concurrence à 5, un serveur DNS personnalisé et en sauvegardant les résultats dans des fichiers distincts :

festin -f cible.com.domaines -

Et pour automatiser tout ça sur plein de domaines à la chaîne, on a même un petit script loop.sh bien pratique dans les examples du repo GitHub.

Voilà les amis, vous avez toutes les clés pour utiliser FestIn comme un pro et aller secouer les buckets S3 qui traînent ! C’est quand même un outil hyper complet et puissant, pensez à l’utiliser avec un proxy ou Tor pour pas vous faire bloquer, et amusez vous bien mais toujours de manière éthique et responsable hein !