La conclusion en 5 secondes : impossible de prouver que l'auteur, Nagano, dessine vraiment plus vite quand l'histoire devient dangereuse. En revanche, il y a bel et bien eu des périodes où l'intervalle entre les publications sur X s'est brusquement resserré, dans des arcs longs et inquiétants ou lors de moments clés. On peut donc faire un bot non officiel qui surveille le rythme de publication comme une série temporelle et n'affiche l'« indice de danger de Chiikawa » que lorsque ce rythme devient anormalement rapide par rapport au passé. Et comme l'API de X est facturée à l'usage en septembre 2026, en ne surveillant qu'un seul compte, on peut démarrer petit.
🍣. Le lendemain, encore 🍣. Le surlendemain, encore une mise à jour.
À ce stade, l'alarme qui retentit dans la tête des lecteurs est presque toujours la même.
« Nagano, il publie un peu vite en ce moment, non ? »
Et quand on a l'impression que Chiikawa publie plus vite, la pensée suivante est étrangement : « quelqu'un devrait peut-être prendre la fuite ? »
Dans cet article, on transforme ce pressentiment de lecteur, approximatif mais bizarrement difficile à jeter, en chiffres. Puis, en partant d'un PC où Python n'est même pas installé, on va jusqu'à l'analyse des données passées, l'exécution à blanc (un essai sans rien publier pour de vrai), la publication automatique sur X et le fonctionnement 24 h/24 avec GitHub Actions. Inutile de déchiffrer le contenu d'un ZIP. Il suffit de copier-coller tels quels les 7 fichiers à la fin de l'article.
Est-ce vraiment « plus c'est dangereux, plus ça publie vite » ?
Quand on regarde l'historique public, il y a pas mal de raisons de le penser. À la fin de l'arc des Sirènes (Seiren), en novembre 2023, d'après les relevés publics, il y a eu des publications 5 jours de suite du 5 au 9 novembre, 6 jours de suite du 13 au 18 et 6 jours de suite du 21 au 26. Le 26 novembre, il y a même eu plusieurs publications le même jour.
Le début de l'arc du Monde parallèle, en mars 2024, a lui aussi eu une publication chaque jour du 1er au 8 mars, avec 2 publications le 8.
Mais tout ce qu'on peut en dire, c'est que « le rythme de publication a augmenté ». Rien ne prouve que l'auteur ait dessiné ces pages le jour même. Il a pu publier à la suite des planches déjà prêtes, ou bien, comme l'arc est long, les publications se sont simplement regroupées.
C'est pourquoi la question posée au bot est volontairement étroite.
Il ne prédit pas les rebondissements dangereux de l'histoire : il détecte à quel point le rythme de publication actuel est anormal par rapport au propre passé de Chiikawa.
Ce n'est pas un laboratoire. C'est un avertisseur Chiikawa.
Que regarde l'indice de danger ?
En gros, seulement trois choses.
- Le nombre de publications des 3 derniers jours
- Le nombre de publications des 7 derniers jours
- Le nombre de jours consécutifs avec publication
Chacune est comparée à la distribution de tout le passé et convertie en percentile : « à quel point on se situe dans le haut de l'historique ». Les pondérations initiales sont de 35 % pour les publications sur 3 jours, 45 % pour celles sur 7 jours et 20 % pour les jours consécutifs. En plus, quand le même court texte ou le même émoji est publié plusieurs fois de suite, comme 🍣🍣, on ajoute une correction pour rire de +5 par répétition supplémentaire, jusqu'à +15.
Ce +5 n'a aucun fondement scientifique. C'est purement l'implémentation de « si les sushis continuent, ça fait un peu peur ».
Les tranches affichées au départ sont les suivantes.
- 0 à 54 : 🟢 Normal
- 55 à 69 : 🟡 Ça s'accélère
- 70 à 84 : 🟠 Vigilance
- 85 à 100 : 🚨 Très rapide
Combien coûte l'API de X ?
Sur la page officielle des tarifs (Pricing) au 3 septembre 2026, les principaux prix en vigueur sont les suivants.
| Opération | Tarif actuel |
|---|---|
| Post Read | $0.005 / publication récupérée |
| Counts: Recent | $0.005 / requête |
| Counts: All | $0.010 / requête |
| Content Create | $0.015 / publication |
| Content Create (avec URL) | $0.200 / publication |
Pour l'analyse du passé, on ne lit pas le texte de milliers de publications : avec Post Counts, on récupère uniquement le nombre de publications par tranche horaire. Les Counts de l'archive complète sont paginés par tranches de 31 jours ; du 1er janvier 2020 au 3 septembre 2026, soit environ 2,437 jours, cela fait environ 79 requêtes, donc environ $0.79. Ce n'est pas « un centime par requête, donc toute l'histoire pour un centime ». C'est le petit piège.
La surveillance en direct utilise Recent Search avec since_id et ne lit que les publications plus récentes que la dernière fois. Avec 30 nouvelles publications, la lecture coûte environ $0.15. Si vous émettez 10 alertes par mois sans URL, l'écriture coûte environ $0.15. À l'inverse, une publication avec URL coûte actuellement $0.200, d'où le réglage initial INCLUDE_SOURCE_URL=0. Si, par gentillesse, vous ajoutez l'URL à chaque fois, la facture devient soudain le boss final.
Les prix peuvent changer. Avant une utilisation réelle, revérifiez le Pricing officiel et définissez un Spending limit (plafond de dépenses) dans la Developer Console.
Si je n'ai pas de PC du tout, par où commencer ?
Il faut un PC sous Windows ou macOS, un compte X, une X Developer App, un compte GitHub si vous voulez le faire tourner 24 h/24, et Python. Git n'a pas besoin d'être installé en local.
Windows
- Installez Python depuis son site officiel. Sous Windows récent, on peut aussi utiliser le Python Install Manager.
- Ouvrez PowerShell.
- Tapez
py --versionpour vérifier que Python se lance. - Créez le dossier
chiikawa-danger-bot. - Avec le Bloc-notes ou VS Code, enregistrez les 7 fichiers de la fin de l'article avec leur nom exact. Avec le Bloc-notes, veillez à ce que le fichier ne devienne pas
bot.py.txt.
macOS
- Installez la version macOS depuis le site officiel de Python.
- Ouvrez le Terminal.
- Vérifiez avec
python3 --version. - Créez le dossier
chiikawa-danger-bot. - Enregistrez les 7 fichiers avec VS Code, TextEdit en mode texte brut ou
nano.
Comment configurer X Developer ?
Connectez-vous à console.x.com avec votre compte X, lisez le Developer Agreement (contrat développeur) puis créez une App. Les identifiants affichés à la création de l'App peuvent ne plus être réaffichés, alors conservez-les dans un endroit sûr.
Pour la lecture, on utilise le Bearer Token. Comme le bot publie lui-même, cette implémentation utilise aussi OAuth 1.0a User Context. Réglez les App permissions sur Read and write.
Il faut cinq valeurs.
X_BEARER_TOKENX_API_KEYX_API_SECRETX_ACCESS_TOKENX_ACCESS_TOKEN_SECRET
Si vous êtes passé de Read only à Read and write, régénérez l'Access Token / Secret après le changement. Utiliser un jeton antérieur à la modification des permissions provoque une erreur 403.
Les vraies valeurs ne vont que dans .env et dans les GitHub Actions Secrets. Ne les collez jamais dans un article, sur un GitHub public ou dans une capture d'écran.
Comment lancer l'analyse des données passées ?
Une fois les 7 fichiers de la fin enregistrés, sous Windows, exécutez ceci dans PowerShell.
py -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
mkdir data
copy danger_periods.example.csv data\danger_periods.csv
copy .env.example .env
notepad .env
Sous macOS, c'est ceci.
python3 -m venv .venv
./.venv/bin/python -m pip install -r requirements.txt
mkdir -p data
cp danger_periods.example.csv data/danger_periods.csv
cp .env.example .env
nano .env
Collez le vrai Bearer Token à droite de X_BEARER_TOKEN= dans .env. Ensuite, sous Windows, lancez
.\.venv\Scripts\python.exe history_analysis.py
et sous macOS
./.venv/bin/python history_analysis.py
Vous verrez défiler page=1... ; si data/history_features.csv est créé, c'est réussi. Ce CSV sert de référence historique pour l'indice de danger.
Dans danger_periods.example.csv, j'ai mis la fin de l'arc des Sirènes et le début de l'arc du Monde parallèle pour vérifier l'hypothèse. Ce ne sont pas des « étiquettes de bonne réponse sur le danger », mais des étiquettes manuelles pour voir si l'indice diffère vraiment entre les périodes dangereuses et les périodes normales.
Comment éviter de publier sur X du premier coup ?
Même si vous avez renseigné les 4 autres identifiants dans .env, laissez d'abord BOT_DRY_RUN=1.
Windows :
.\.venv\Scripts\python.exe bot.py
macOS :
./.venv/bin/python bot.py
La première fois, il lit environ les 7 derniers jours et crée seulement data/state.json ; il ne publie absolument rien. Par exemple, l'écran affiche ceci.
Indice de danger Chiikawa 82/100 🟠 Vigilance
3 derniers jours : 3 publications / 7 jours : 6 publications / 3 jours consécutifs
Même marqueur « 🍣 » 2 fois de suite +5
* Non officiel. Indicateur pour rire, construit à partir de la fréquence de mise à jour.
Voilà, la méthode de lecture de Chiikawa inutilement technique est complète : Nagano publie à la chaîne → Python : « anomalie dans la série temporelle » → les lecteurs : « fuyez ».
Comment le faire tourner 24 h/24 avec GitHub Actions ?
Créez un nouveau Repository GitHub dans le navigateur et téléversez ceci.
bot.pyhistory_analysis.pyrequirements.txt.env.example.gitignoredata/history_features.csv- Si nécessaire,
data/danger_periods.csv
Ne téléversez jamais .env.
Dans Settings → Secrets and variables → Actions → New repository secret du Repository, enregistrez les cinq identifiants sous les mêmes noms.
Ensuite, avec Add file → Create new file, créez .github/workflows/chiikawa-danger.yml et collez le YAML de la fin. La valeur initiale est BOT_DRY_RUN: "1". Lancez-le manuellement depuis l'écran Actions et vérifiez qu'il se termine normalement.
Ne passez à BOT_DRY_RUN: "0" qu'au moment de la mise en production. Avec POST_MODE: "alert", il ne publie que lorsque la tranche de danger monte d'un cran. Avec every, il publie à chaque nouveauté : le coût comme la pression sur la timeline augmentent.
Que respecter en tant que bot automatique ?
Les Automation Rules de X imposent d'éviter le spam, l'automatisation répétitive et ce genre de pratiques. Les comptes automatisés peuvent porter l'Automated account label (étiquette de compte automatisé) et préciser leur lien avec le compte géré par un humain.
Dans le profil, indiquez clairement « bot de fans non officiel » et « indicateur pour rire construit à partir de la fréquence de mise à jour », et n'imitez pas le compte officiel. Cet exemple ne fait ni likes automatiques, ni abonnements automatiques, ni réponses en masse.
De plus, l'« indice de danger » n'affirme rien sur la santé de l'auteur, sa vitesse de dessin réelle, ses conditions de travail ou la suite de l'histoire. Ce qui est observé, c'est uniquement le motif horaire des publications publiques.
Et si on veut pousser le bricolage encore plus loin ?
On peut aussi ajouter une correction selon le jour de la semaine, classer les annonces et les chapitres de l'histoire, utiliser les caractéristiques des images, entraîner un modèle avec des étiquettes faites à la main, faire un backtest (vérification sur des données passées) du nombre de jours après lequel un chapitre inquiétant arrive après une alerte, ou chercher des périodes similaires comme le « type fin des Sirènes » et le « type Monde parallèle ». Mais la quantité de données et le coût augmentent.
Au début, l'heure de publication suffit. À partir du moment où un bot pour rire devient de la détection d'anomalies sur série temporelle, c'est déjà assez absurde.
Alors, qu'est-ce qu'on prédit au final ?
Pas « qui va souffrir la prochaine fois ».
À quel point le rythme de mise à jour actuel est anormal par rapport au Chiikawa du passé.
C'est tout.
Mais puisque la fin de l'arc des Sirènes et le début de l'arc du Monde parallèle ont réellement vu les publications se resserrer, c'est déjà assez amusant pour automatiser ce pressentiment de lecteur : « ça recommence à accélérer ».
Indice : 85 points.
La machine : « Dans le haut de l'historique. »
Les lecteurs : « Que quelqu'un fuie ! »
