Études de cas · Comptabilité au Japon

Notre comptabilité japonaise, reconstruite en trois heures et demie

QkSkima est une K.K. au Japon. Comme toute entreprise japonaise, nous avons besoin d'une comptabilité propre : opérations bancaires, justificatifs et, chaque mois, les fichiers pour notre expert-comptable. En un après-midi, nous avons passé tout ce processus sur notre propre application, en trois heures et demie. Voici comment, preuves horodatées à l'appui.

de la première instruction au dernier test: 3 h 30; de la première instruction au dernier test
changement au format de l'expert-comptable: 0; changement au format de l'expert-comptable
mot de passe : connexion par passkey uniquement: 0; mot de passe : connexion par passkey uniquement
barrières avant chaque écriture: 3; barrières avant chaque écriture

Le point de départ

Jusqu'ici, notre comptabilité tournait sur un logiciel du marché. Chaque mois, il écrivait dans un dossier un fichier CSV avec les écritures, les justificatifs et un fichier ZIP. Notre expert-comptable lit ce dossier.

Nous voulions maîtriser notre comptabilité : nos propres données, nos propres processus et une application qui corresponde exactement à notre façon de travailler. En même temps, rien ne devait changer pour l'expert-comptable. Et comme il s'agit de données bancaires, la nouvelle application devait être plus sûre que l'ancienne.

Les exigences

Le dossier reste tel quel

L'expert-comptable attend une structure de dossiers, des noms de fichiers et des colonnes fixes. Même les catégories doivent rester identiques au mot près. La nouvelle application écrit donc exactement les mêmes fichiers que l'ancien logiciel.

Le relevé arrive en Shift_JIS

Les banques japonaises livrent des fichiers CSV dans un ancien encodage japonais. Quelques caractères y sont codés différemment selon la variante. L'application corrige cela pour que les libellés soient exactement les mêmes que dans les anciens exports.

Les anciennes écritures suivent

Toutes les écritures et tous les justificatifs ont été repris, avec leurs anciens numéros. Les nouvelles écritures continuent simplement la numérotation. Les justificatifs ont été rattachés à la bonne écriture grâce à leur nom de fichier.

Rien ne se perd

Avant qu'un export remplace des fichiers, l'application copie les anciens dans une sauvegarde. Chaque fichier est d'abord écrit en entier, puis mis à sa place : il n'y a jamais de fichier à moitié écrit dans le dossier.

Aucun relevé n'est saisi deux fois

Chaque écriture reçoit une empreinte faite de la date, du libellé, du montant et du solde. Si le même relevé est importé deux fois, l'application ignore tout ce qui existe déjà.

Nous seuls pouvons entrer

Les données bancaires n'ont rien à faire sur l'internet ouvert. L'application n'est accessible que depuis des réseaux autorisés, et la connexion exige une passkey. Il n'y a pas de mot de passe.

La preuve : trois heures et demie en horodatages

Nous ne nous contentons pas d'affirmer que c'était rapide. Le système de fichiers et le journal de la session de développement enregistrent quand chaque fichier a été créé. Voici les horodatages du 3 novembre 2026, heure du Japon.

10:59

2026-11-03-Buchhaltung/

Dossier du projet créé. Jusqu'à 11:52, les anciens exports et un relevé bancaire y sont copiés comme modèles.
11:54

Journal de session, premier message

Le développement commence : première instruction à Claude Code.
11:56

Gemfile

L'application Rails est créée.
11:58

app/services/month_exporter.rb

Export au format de l'expert-comptable : CSV, justificatifs, fichier ZIP, avec sauvegarde.
12:00

lib/ip_whitelist.rb · …_statement_importer.rb

Liste blanche d'adresses IP et import du relevé bancaire.
12:01

app/controllers/sessions_controller.rb

Connexion uniquement par passkey.
14:48

.claude/skills/resolve-contacts/

Outils d'IA qui attribuent les contacts manquants.
15:16

app/controllers/receipt_reviews_controller.rb

Revue des justificatifs : compléter les factures manquantes par fournisseur.
15:21

Journal de session, dernier message

Dernière modification. 42 tests, 0 échec.

Du relevé bancaire à l'expert-comptable

1
Lire le relevé bancaire

Le fichier CSV de la banque est téléversé. L'application lit l'encodage japonais, crée une écriture par ligne et ignore ce qui est déjà importé. Elle reprend le contact et la catégorie de la dernière écriture au même libellé, ou d'après des mots-clés.
2
Vérifier et ajouter les justificatifs

Les écritures sans contact ni catégorie sont signalées. La revue des justificatifs montre toutes les écritures ouvertes de l'année, groupées par fournisseur. On se connecte donc une seule fois chez chaque fournisseur et on téléverse toutes ses factures d'un coup. Si aucun justificatif n'est nécessaire, un clic suffit.
3
Exporter le mois

Un clic écrit le mois dans le dossier de l'expert-comptable, exactement à l'ancien format. Ce qui est remplacé est sauvegardé avant. L'expert-comptable travaille comme avant.

L'application

Tous les écrans montrent des données d'exemple. Entreprises, montants et numéros de compte sont inventés.

La vue mensuelle d'un compte : recettes, dépenses, solde et nombre d'écritures encore sans justificatif. Les écritures inconnues sont signalées en jaune.

Un relevé bancaire importé. Contact et catégorie sont proposés d'après les écritures précédentes ; trois lignes déjà présentes ont été ignorées.

La revue des justificatifs : toutes les écritures ouvertes de l'année, groupées par fournisseur. Téléverser, ou décider avec « No receipt » qu'aucun n'est nécessaire. La barre montre l'avancement.

Les contacts, avec catégorie par défaut et mots-clés. Le prochain import s'en sert pour reconnaître automatiquement les nouvelles écritures.

L'export dans le dossier de l'expert-comptable, avec la structure de dossiers fixe et l'historique des exports.

Sécurité : trois barrières avant chaque écriture

Une comptabilité contient des soldes, des salaires et des impôts. Chaque requête doit donc passer trois barrières avant de voir la moindre écriture.

1. Liste blanche d'adresses IP avant tout

Avant même l'application, une barrière contrôle l'adresse de chaque requête. Si elle ne vient pas d'un réseau autorisé, la réponse est simplement « Forbidden ». Cela vaut pour chaque page, chaque image et chaque téléversement. De l'extérieur, même la page de connexion est invisible.

2. Des passkeys au lieu de mots de passe

La connexion fonctionne uniquement par passkey (WebAuthn). La clé reste sur votre appareil et se déverrouille par empreinte digitale ou reconnaissance faciale. Elle ne vaut que pour cette adresse précise. Il n'y a donc aucun mot de passe à deviner, intercepter ou demander sur une fausse page.

3. Chaque compte démarre verrouillé

Toute personne qui s'inscrit est d'abord verrouillée. Elle n'entre que lorsque son adresse e-mail figure sur la liste autorisée. Si l'adresse est retirée, le compte est verrouillé aussitôt, même dans les sessions ouvertes.

Et les bases

HTTPS uniquement, des cookies de session illisibles par les scripts et un frein aux tentatives de connexion : dix au maximum en trois minutes.

La connexion : une passkey au lieu d'un mot de passe. La page elle-même n'est accessible que depuis des réseaux autorisés.

L'IA là où elle fait gagner du temps

Au Japon, les libellés bancaires sont souvent difficiles à lire, par exemple des katakana demi-chasse comme ﾔﾊﾀｾﾞｲﾑｼﾖ (un centre des impôts) ou des noms de commerçants obscurs sur les paiements par carte. Pour cela, nous avons créé deux outils pour Claude Code. Le premier attribue les contacts connus. Le second lit les libellés inconnus, trouve quelle entreprise se cache derrière et propose de nouveaux contacts avec des mots-clés. Rien n'est écrit avant qu'une personne ait validé la proposition.

Le résultat

Toute la comptabilité tourne dans notre propre application, qui correspond exactement à notre façon de travailler.
L'expert-comptable reçoit les mêmes dossiers et fichiers qu'avant. Rien n'a changé pour lui.
Toutes les anciennes écritures et tous les justificatifs sont repris, la numérotation continue.
Rassembler les justificatifs va plus vite : une connexion par fournisseur au lieu d'une par écriture.
Sans réseau autorisé et sans passkey, personne n'accède aux données.

Ce que cela signifie pour votre entreprise au Japon

Beaucoup d'entreprises européennes au Japon ont le même problème en plus grand : la filiale japonaise comptabilise dans un logiciel japonais, l'expert-comptable veut son format, et le siège veut les chiffres dans son propre système.

C'est exactement ce type de transition que nous construisons : lire les données bancaires japonaises, traduire les formats, rattacher les justificatifs et tout sécuriser pour que seules les bonnes personnes y aient accès. Cela va souvent plus vite qu'on ne le pense quand les exigences sont claires dès le départ.

Guide sur ce sujet

Le Japon comptabilise dans freee, le siège veut des chiffres groupe — et chaque mois quelqu'un construit un tableur

Lire la suite →

Technique

Ruby on Rails 8.1, SQLite
Hotwire (Turbo, Stimulus)
WebAuthn pour les passkeys
Middleware Rack pour la liste blanche d'adresses IP
Claude Code pour attribuer les contacts

Questions fréquentes

Un logiciel du marché n'aurait-il pas suffi ?

Pour beaucoup d'entreprises, si. Mais nous voulions garder nos propres données, respecter exactement le format de l'expert-comptable et sécuriser l'accès plus strictement que la plupart des logiciels du marché ne le permettent.

Les images montrent-elles de vraies données ?

Non. Tous les écrans proviennent d'une copie de l'application avec des entreprises, des montants et des numéros de compte inventés.

Pouvez-vous faire cela pour notre entreprise ?

Oui. Nous construisons et connectons des systèmes pour des entreprises européennes au Japon, par exemple entre la comptabilité japonaise, l'expert-comptable et le siège. Le conseil fiscal reste du ressort de votre expert-comptable.