Le 24 septembre 2026, le Japon a remplacé en profondeur son système fiscal national. Aussitôt après, les guichets des centres des impôts ont mis « un temps considérable » à encaisser des paiements en espèces ou à délivrer des attestations de paiement d'impôts, et le portail de déclaration en ligne e-Tax a enchaîné plusieurs dysfonctionnements et maintenances d'urgence. Qu'un énorme système intégré devienne instable juste après la bascule, quiconque a déjà touché à des systèmes distribués ou à l'automatisation de tâches le comprend aisément. Mais « comprendre que ça casse » et « avoir une porte de sortie suffisante quand ça casse » sont deux problèmes bien distincts.
Imaginez que vous avez une démarche urgente et qu'au guichet on vous dise : « Le système est en panne générale, on ne sait pas quand il sera rétabli. Si c'est pressé, venez sur place, on s'occupera de vous. »
Le réflexe, c'est de se dire : « Alors j'y vais, et voilà. »
Mais si on y réfléchit un peu, le tableau devient moins réjouissant.
Les gens qui ne peuvent pas régler leur dossier en ligne ou par la voie habituelle affluent au guichet. Du côté des agents, le système est instable et chaque dossier prend plus de temps. Il vient plus de monde alors que la capacité de traitement baisse.
« Venez, on s'occupe de vous » ne veut pas dire « venez, c'est réglé en deux secondes ».
Du coup, si votre échéance n'est pas imminente, attendre devient un choix tout à fait rationnel.
Et on a envie de crier intérieurement :
« Prenez les dossiers sur papier, maintenant, sérieusement. »
Sauf que le papier n'est pas une base de données de secours magique.
1. Que s'est-il passé en septembre 2026
L'Agence fiscale nationale japonaise (NTA) a renouvelé son système le 24 septembre 2026. Pour le système de nouvelle génération, KSK2, la NTA avançait depuis longtemps trois idées directrices :
- Passer d'un traitement centré sur les documents papier à un traitement centré sur les données
- Unifier les bases de données et applications qui étaient jusque-là séparées par type d'impôt
- Remplacer les gros ordinateurs centraux à système d'exploitation propriétaire par des systèmes ouverts fonctionnant sur des systèmes d'exploitation courants
Autrement dit, il ne s'agit pas d'un simple ravalement des écrans. La façon de stocker les données, les frontières entre applications et l'infrastructure elle-même changent en même temps : c'est un renouvellement de grande ampleur.
Le jour même de la bascule, le 24 septembre, la NTA a publié un avis sur les « retards des démarches aux guichets des centres des impôts ». Elle expliquait que l'encaissement en espèces, la délivrance d'attestations de paiement d'impôts et d'autres démarches demandaient un temps considérable, et que même une demande via e-Tax ne permettait pas une délivrance immédiate. Le renouvellement lui-même était achevé, mais le fonctionnement des systèmes nécessaires au service au guichet posait problème.
Durant cette même semaine de bascule, il y a eu aussi des problèmes de connexion via Mynaportal (le portail des démarches administratives lié à la carte de numéro personnel), des erreurs d'affichage de la confirmation de paiement par banque en ligne, l'arrêt de certaines fonctions d'e-Tax et des maintenances d'urgence pour traiter les incidents. L'arrêt de certaines fonctions d'e-Tax a été annoncé comme résolu avant le 27 septembre.
D'un autre côté, l'avis sur les retards aux guichets figurait encore le 28 septembre parmi les informations urgentes du site de la NTA. La cause profonde détaillée n'avait pas été rendue publique à ce moment-là.
Plus important encore : il ne faut pas confondre maintenance programmée et panne. Pour ce renouvellement, un long arrêt était déjà prévu du 19 septembre à 0 h jusqu'au 24 à 8 h 30, ainsi qu'un arrêt toute la journée du 26 septembre. Sont venus s'y ajouter les dysfonctionnements post-bascule et les maintenances d'urgence.
Il est donc naturel d'avoir l'impression que « c'est tout le temps à l'arrêt », mais cela mêle des arrêts planifiés et des arrêts dus à des pannes.
2. Même un système sérieux qui gère de l'argent tombe en panne. Parfois, c'est justement pour ça qu'on l'arrête
« Si c'est un système qui gère les impôts et l'argent, on le conçoit forcément pour qu'il ne s'arrête jamais, non ? »
Intuitivement, oui.
Mais, pour un système critique, il n'y a pas que la disponibilité : il y a aussi la cohérence.
Dans un traitement de paiement, par exemple, le plus redoutable n'est pas qu'un écran mette cinq minutes à s'ouvrir.
- Vous avez payé mais vous apparaissez comme impayé
- Une même opération est enregistrée deux fois
- Une attestation est délivrée à partir de données périmées
- Un seul des deux systèmes est mis à jour, l'autre reste à la traîne
- En relançant après le rétablissement, la même opération s'exécute une seconde fois
Dans cet état, « on l'a laissé tourner quand même » peut être plus dangereux qu'un arrêt.
Les ressources SRE (ingénierie de la fiabilité des sites) de Google expliquent aussi que, lors d'une panne majeure, mieux vaut d'abord limiter l'étendue des dégâts avant de chercher la cause profonde, et que s'il y a un risque de corruption des données, il peut être préférable de geler le système.
Ce n'est pas qu'il s'arrête alors qu'il s'agit d'argent.
C'est que, justement parce qu'il s'agit d'argent, il faut parfois décider d'arrêter plutôt que de laisser tourner sans pouvoir garantir un état correct.
Si « avez-vous essayé de redémarrer ? » réglait tout, les exploitants des systèmes centraux du pays rentreraient bien plus tôt chez eux.
3. Même si tous les tests unitaires passent, l'intégration explose quand même
Le pire avec les systèmes intégrés, c'est que chaque pièce peut être normale et l'ensemble cassé.
Le système A fonctionne.
Le système B aussi.
La base de données aussi.
L'authentification aussi.
Et pourtant, si le format transmis de A à B diffère d'un seul caractère, tout s'arrête.
Si les données migrées de l'ancien système vers le nouveau contiennent une valeur exceptionnelle, tout s'arrête.
Si, au milieu d'une nouvelle tentative, seule la réponse se perd, on ne sait plus si l'opération a été traitée ou non.
Anciens caches, anciens formulaires, connexions avec des organismes extérieurs, droits d'accès, horloges, traitements par lots, encodage des caractères, anciennes graphies de caractères, réémissions après panne. Plus il y a de frontières, plus il y a de combinaisons invisibles quand on teste chaque pièce isolément.
Même une petite automatisation personnelle tourne facilement à l'accident à cause d'états anciens, d'exécutions en double, d'oublis, de différences d'API externes et d'effets de bord des nouvelles tentatives.
Il faut maintenant faire cela sur un système central qui couvre les centres des impôts de tout le pays, plusieurs impôts, les encaissements, les remboursements, les attestations, e-Tax et des organismes extérieurs.
Plus on sait à quel point l'intégration est difficile, plus on se dit : « bon, juste après la bascule, il y a toujours quelque chose qui sort ».
Mais ce n'est pas un blanc-seing.
Ce qu'il faut évaluer, ce n'est pas seulement l'absence de toute panne, mais jusqu'où l'on a pu réduire le service en toute sécurité quand les pannes sont arrivées.
4. Pourquoi on en arrive à « pas de date de rétablissement prévue »
Pour l'utilisateur, c'est l'une des phrases les plus exaspérantes :
« La date de rétablissement n'est pas fixée. »
Mais promettre une heure au hasard alors que la cause est inconnue peut être plus dangereux.
Rétablir un système critique, ce n'est pas simplement rallumer le serveur.
On commence par délimiter l'étendue de la panne.
Puis on vérifie que des données n'ont pas été écrites à moitié.
On vérifie qu'une ré-exécution ne provoquera pas de traitement en double.
On vérifie que l'état n'est pas divergent avec les systèmes externes connectés.
Si nécessaire, on envisage un retour en arrière ou une voie de contournement.
Après le rétablissement, on fait passer dans l'ordre les traitements accumulés pendant l'arrêt et on rapproche les résultats.
C'est particulièrement pénible quand apparaît un état du genre « côté émetteur, cela semble réussi, mais côté récepteur, ce n'est pas confirmé ».
Dans un texte d'Amazon sur la conception de systèmes distribués, on explique aussi que, pour sécuriser les nouvelles tentatives, l'idempotence est essentielle : renvoyer la même requête ne doit pas dupliquer ses effets.
Ne pas pouvoir donner d'heure de rétablissement ne prouve pas que les responsables ne font rien.
Tant qu'on ne sait pas jusqu'où cela a cassé, jusqu'où l'on peut revenir en arrière et à partir d'où reprendre sans traiter deux fois, une prévision précise est déjà difficile en soi.
5. « Si c'est urgent, venez au guichet » : en termes de file d'attente, c'est assez effrayant
C'est là que le guichet entre en scène.
Même quand le système est en panne, on dit parfois : « venez sur place, on s'en occupera ».
C'est une porte de sortie appréciable.
Mais du point de vue du temps d'attente, plusieurs conditions dangereuses se cumulent.
Simplifions le fonctionnement normal.
Appelons λ le nombre de personnes qui arrivent au guichet, et μ le nombre que les agents peuvent traiter.
En cas de panne, deux choses peuvent se produire en même temps.
D'abord, des gens qui régleraient normalement leur dossier en ligne ou par des traitements internes viennent aussi au guichet, donc λ augmente.
Ensuite, les agents ont plus de mal à utiliser le système, les vérifications et saisies manuelles par dossier augmentent, donc μ diminue.
La demande monte et la capacité de traitement baisse.
Pour une file d'attente, c'est la pire combinaison.
Et les agents des centres des impôts ne se multiplient pas tout seuls au moment où la panne survient.
Les ressources SRE de Google indiquent aussi que, près de la surcharge, un système ne ralentit pas simplement un peu : il peut se dégrader de façon non linéaire à cause de l'allongement des attentes et des pannes en cascade. C'est pourquoi le contrôle de la charge et les réponses en service réduit sont importants.
« Venez au guichet, on s'en occupera » ne veut pas dire « le guichet est vide ».
Si votre échéance laisse de la marge, ne pas foncer le jour du pic de la panne et attendre le rétablissement est une décision parfaitement rationnelle en termes de coût en temps.
En revanche, si une échéance légale ou une urgence est en jeu, ne laissez pas traîner sur votre seule appréciation : consultez les avis officiels de la NTA ou du centre des impôts à ce moment-là pour connaître les solutions de remplacement.
6. « Faites-le sur papier » est à moitié juste. Le papier sert de porte de sortie pour la réception, mais ce n'est pas une base de données de secours
À force d'observer ces pannes, une idée finit par s'imposer :
« On n'a qu'à recevoir les dossiers sur papier. »
Cette idée n'est pas entièrement fausse.
Le guide de planification de la continuité pour les systèmes d'information du NIST (l'institut de normalisation américain) cite aussi, comme mode de traitement de remplacement en cas de panne, l'exécution manuelle de tout ou partie des processus métier pendant une courte période.
Autrement dit, le traitement manuel est bel et bien une mesure de continuité légitime.
Mais cela ne veut pas dire qu'« écrire sur papier règle tout ».
Ce que le papier permet, c'est par exemple ceci :
- Garder la trace qu'une demande ou une consultation a bien été reçue
- Fixer la date et l'heure de réception
- Garder les pièces nécessaires
- Établir un ordre de traitement pour après le rétablissement
- Remettre un numéro de dossier ou un récépissé
En revanche, le rapprochement avec les données centrales, la vérification de l'état des paiements, la consultation des historiques, la délivrance exacte des attestations et la liaison avec les organismes extérieurs peuvent ne pas être réalisables sans le système central.
L'idéal n'est donc pas de « tout ramener au papier ».
C'est que, même si le système central tombe, la réception ne tombe pas avec.
Le papier n'est pas une base de données de secours.
Mais un récépissé en papier peut faire office d'issue de secours.
7. Ce qu'il faut vraiment, c'est un « mode dégradé » qui ne s'arrête jamais complètement
Un système résistant aux pannes ne conserve pas forcément 100 % de ses fonctions normales.
Au contraire, il ne garde que les fonctions essentielles et bascule en mode simplifié.
Google SRE traite cela comme une dégradation progressive des fonctions, ce qu'on appelle la graceful degradation. Le NIST cite aussi les installations de remplacement, les sites de remplacement et le traitement manuel parmi les options d'un plan de continuité.
Appliqué aux démarches fiscales, l'idéal ressemblerait à ceci :
- Ne pas arrêter la réception. Pouvoir recevoir au minimum les informations essentielles de la demande, hors ligne ou sur papier.
- Délivrer un numéro de réception. Supprimer le « je ne sais pas si c'est bien arrivé ».
- Placer dans une file de traitement différé. Pouvoir retraiter dans l'ordre après le rétablissement.
- Empêcher le double traitement. Avoir un identifiant qui fait qu'une même demande, même saisie à nouveau, ne compte qu'une fois.
- Distinguer les degrés d'urgence. Donner la priorité à ce qui a une échéance ou un fort impact sur la vie des gens.
- Montrer l'état aux usagers. Annoncer séparément ce qui est arrêté, ce qui fonctionne et ce qui est rétabli.
- Rapprocher après le rétablissement. Confronter les réceptions sur papier ou hors ligne aux données de production pour détecter les oublis et les doublons.
L'important n'est pas l'illusion que « même en cas de panne, tout continue comme avant ».
C'est de concevoir la manière dont ça casse.
8. Alors, à quelle fréquence e-Tax pose-t-il problème ?
Quand on regarde les avis officiels d'e-Tax pour 2026, on relève plusieurs annonces d'incidents tout au long de l'année : en janvier, un retard de notification de paiement effectué ; en février, des dysfonctionnements de la liaison avec Mynaportal et des difficultés de connexion ; en mars, des difficultés de connexion ; en juillet, des dysfonctionnements via Mynaportal ; en août, l'indisponibilité du paiement direct et d'autres fonctions ; et en septembre, plusieurs dysfonctionnements juste après le renouvellement.
Mais ici, il ne faut pas compter à la légère.
Ce ne sont pas tous le même incident.
Il y a des problèmes d'e-Tax lui-même, mais aussi de liaison avec Mynaportal, de paiement, d'affichage et de services externes. De plus, une maintenance programmée n'est pas une panne.
La liste officielle permet donc seulement de dire que « des dysfonctionnements partiels et des pannes de liaisons périphériques sont annoncés plusieurs fois par an », pas que « le système fiscal tout entier tombe en panne dans tout le pays à tout bout de champ ».
Septembre 2026 se remarque surtout parce que, durant la semaine de bascule d'un renouvellement géant, un long arrêt planifié et plusieurs dysfonctionnements post-bascule se sont cumulés.
9. Quand on connaît l'enfer de l'intégration, on ne s'énerve plus tout à fait pareil
Quand on a déjà construit un petit système automatisé, on regarde un peu autrement les pannes des gros systèmes.
Avant, la réaction était :
« Comment un truc pareil peut-il s'arrêter ? »
Et ça s'arrêtait là.
Dès qu'on a relié plusieurs services, utilisé des files, ajouté des nouvelles tentatives, sauvegardé des états et branché des API externes, une autre réaction s'y mêle :
« Aïe, une bascule de système intégré. Ça, c'est l'enfer. »
Chaque morceau marche seul, mais l'ensemble casse.
On répare, et une autre frontière casse.
Des états anciens subsistent.
On réessaie et ça se duplique.
On regarde les journaux et c'était l'information d'hier.
Rien que d'avoir vécu une version miniature de cela, on imagine mieux la difficulté d'un énorme système central.
Mais comprendre n'est pas évaluer.
Plutôt que de conclure par « c'est difficile, on n'y peut rien », il faut regarder ceci :
- Jusqu'où les tests de charge et de migration ont été menés avant la bascule
- Jusqu'où l'on a pu fonctionner en service réduit pendant la panne
- Jusqu'où la réception manuelle a fonctionné
- Si les annonces d'état étaient suffisantes pour les usagers
- Si la cause et les mesures de prévention seront publiées après le rétablissement
- Si la prochaine bascule permettra d'éviter le même type d'accident
Parce que c'est complexe, des accidents peuvent survenir.
Justement parce que c'est complexe, la conception et l'apprentissage après l'accident comptent.
10. Conclusion : non pas « tout sur papier », mais « même sur papier, ne laissez pas mourir la porte d'entrée »
Quand le système central d'un centre des impôts s'arrête, c'est assez injuste du point de vue de l'usager.
C'est un lieu qui gère de l'argent et des démarches légales, et il s'arrête.
On ne sait même pas quand ce sera rétabli.
On vous dit que le guichet peut vous aider, mais il sera forcément bondé.
Alors on a envie de dire : « faites-le donc sur papier ».
Dans ce sentiment se cache une exigence de conception assez importante.
Remplacer tout le système fiscal par du papier seul n'est pas réaliste.
Mais il n'y a pas non plus de raison que la réception, l'enregistrement, la hiérarchisation et la file de traitement différé meurent en même temps que le système.
Ce dont un système géant a besoin, ce n'est pas du mythe du « ça ne cassera jamais ».
C'est que, même cassé, il reste au moins le travail minimal.
Qu'on puisse revenir en arrière sans double traitement.
Qu'on dise aux usagers ce qui fonctionne et ce qui ne fonctionne pas.
Et qu'après le rétablissement, on puisse rattraper en sécurité le travail resté en suspens.
Voici donc l'exigence finale :
Ce n'est pas « tout sur papier ».
C'est « que la réception, au moins, puisse tenir debout sur papier. Sérieusement. »
Sources
- Agence fiscale nationale (NTA), « À propos des retards des démarches aux guichets des centres des impôts », 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, « À propos du renouvellement du système fiscal national »
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - Rapport de la NTA 2025, « Système de nouvelle génération (KSK2) »
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, « À propos des horaires de maintenance liés au renouvellement du système fiscal national »
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, « Liste des avis »
https://www.e-tax.nta.go.jp/topics/ - e-Tax, « [Résolu] À propos de l'indisponibilité d'e-Tax »
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
