Réparer la synchronisation bancaire Odoo
Un matin, les relevés ne descendent plus. Vous ouvrez la connexion bancaire, vous cliquez sur Reconnect, et Odoo répond : Computed signature is not identical to provided signature. Le message est technique, il ne dit rien de la cause, et il revient sur chaque bouton.
Cet article explique le mécanisme, montre comment lire les vrais indices, et déroule la correction pas à pas. Il s’applique à Odoo 17, 18 et 19, en ligne comme sur votre propre hébergement.
1. Le symptôme
Tous les boutons de la connexion échouent : Reconnect, Update Credentials, Fetch Transactions, Extend consent. L’état de la connexion est passé à disconnected et le tableau de bord affiche un bouton rouge « Reconnect Bank » qui ne mène à rien.
Le signe qui ne trompe pas : si vous avez plusieurs banques et qu’elles tombent toutes en même temps alors qu’elles passent par des fournisseurs différents, ce n’est pas un incident bancaire. La cause est chez vous.
2. Comment la synchronisation bancaire fonctionne réellement
Votre Odoo ne parle jamais directement à votre banque. Il passe par un intermédiaire hébergé par Odoo, le proxy OdooFin, qui s’adresse lui-même à un agrégateur bancaire (Saltedge, EnableBanking, Ponto selon les cas), lequel dialogue avec la banque.
Chaque appel vers ce proxy est signé. Odoo fabrique une empreinte HMAC-SHA256 à partir de l’horodatage, du chemin appelé, de votre identifiant client, des paramètres et du corps du message. La clé de cette empreinte est un jeton secret, le refresh_token, stocké dans votre base.
À réception, le proxy refait le même calcul avec le jeton qu’il détient de son côté. Si les deux empreintes diffèrent, il refuse : Computed signature is not identical to provided signature.
Le point important : le message, le chemin et l’horodatage voyagent avec la requête. Ils ne peuvent pas diverger. Seule la clé peut diverger. Autrement dit : le jeton de votre base n’est plus celui du proxy.
3. L’erreur affichée n’est presque jamais la première
C’est l’étape que l’on saute, et c’est celle qui donne la réponse. Ouvrez la connexion bancaire et remontez le fil de discussion (le chatter, en bas de la fiche). Odoo y consigne chaque échec, daté.
Sur un cas réel récemment traité, le fil racontait ceci :
| Date | Message consigné par Odoo | Lecture |
|---|---|---|
| 1er du mois, 13h48 | Account not found — This connection has been deleted and won’t work anymore. Please delete it and link with your bank again. | Le proxy a supprimé le compte. Quatre connexions, trois fournisseurs différents, à la même minute. |
| Six jours plus tard | Computed signature is not identical to provided signature | Conséquence mécanique : sans compte chez le proxy, plus aucun jeton pour vérifier la signature. |
L’erreur de signature était le symptôme, pas la cause. Odoo avait donné la marche à suivre six jours plus tôt, dans un message que personne n’avait ouvert.
4. Les causes possibles
| Cause | Indice caractéristique |
|---|---|
| Base dupliquée ou restaurée (migration, montée de version, copie de test remise en ligne) | Deux instances portent le même identifiant de base et les mêmes identifiants clients. Toutes les banques tombent ensemble. |
| Deux instances vivantes issues du même dump | Le jeton est tournant : la première des deux qui le renouvelle invalide l’autre, définitivement. |
| Restauration d’une sauvegarde antérieure à un renouvellement de jeton | Une seule instance, mais le jeton en base est plus ancien que celui du proxy. |
| Consentement bancaire expiré (DSP2) | Une seule banque concernée, et une date d’expiration de consentement dépassée sur le journal. |
Le dénominateur commun des trois premières : une copie de base. C’est le prix d’une migration ou d’une restauration qui n’a pas traité l’identité de la base.
5. Aucun bouton ne répare — et voici pourquoi
C’est contre-intuitif, mais Reconnect, Update Credentials et Extend consent sont tous condamnés : avant d’ouvrir la fenêtre de la banque, Odoo commence par demander un jeton d’accès au proxy, avec une requête signée. Elle échoue, et vous ne voyez jamais l’écran de la banque.
Le bouton Connect ne répare rien non plus : il crée une connexion vierge et laisse la connexion cassée en place — en oubliant de détacher vos journaux. Si vous allez au bout, Odoo crée un nouveau journal et vos futurs relevés atterrissent à côté de votre historique.
6. Ce que vous perdez en supprimant la connexion (rien de comptable)
C’est la question qui bloque tout le monde. Supprimer la connexion bancaire supprime :
- le lien vers le fournisseur et son appairage compte bancaire / journal,
- l’état de synchronisation et l’historique des appels.
Et ne touche pas :
- les journaux, qui restent en place avec leur paramétrage,
- les relevés et lignes de relevé déjà importés,
- les écritures comptables et les rapprochements.
Techniquement, le champ « compte en ligne » du journal est simplement vidé. C’est d’ailleurs ce qu’Odoo fait lui-même, automatiquement, quand vous relancez une connexion depuis un journal déjà relié.
Bonne nouvelle supplémentaire : la suppression aboutit même quand la signature est invalide. Odoo prévoit explicitement ce cas, pour ne pas vous laisser avec une connexion morte impossible à retirer.
7. La correction, pas à pas
Étape 0 — Faire l’inventaire (5 minutes, sans rien casser)
- Activer le mode développeur : Paramètres > Développeur > Activer le mode développeur.
- Ouvrir Comptabilité > Configuration > Comptabilité > Online Synchronization. Ce menu n’existe qu’en mode développeur.
- Noter, pour chaque connexion : le nom, l’identifiant client, l’état, le fournisseur.
- Ouvrir chaque fiche et lire le fil de discussion (cf. section 3).
Étape 1 — Neutraliser l’instance concurrente
Si une seconde instance existe (ancienne version conservée, copie de test, plateforme quittée), c’est par elle qu’il faut commencer. Sinon la collision se reproduira sur vos connexions neuves.
- Y supprimer les connexions bancaires, ou à défaut décocher Automatic synchronization sur chacune.
- Si cette instance doit vivre et synchroniser de son côté, il faut régénérer son identifiant de base avant tout ré-appairage. Ne le faites pas à l’aveugle : c’est un geste à cadrer.
Étape 2 — Relever le mapping AVANT de supprimer
C’est l’étape que l’on regrette d’avoir sautée. Pour chaque journal bancaire, noter :
- le nom et le code du journal,
- le numéro de compte bancaire (IBAN) renseigné sur le journal,
- la devise,
- la date de la dernière ligne de relevé.
L’IBAN du journal est le pivot du ré-appairage automatique. S’il est vide ou mal saisi, Odoo ne retrouvera pas votre journal et en créera un neuf. Corrigez-le maintenant.
Étape 3 — Supprimer les connexions cassées
- Depuis l’écran Online Synchronization, sélectionner les connexions en erreur.
- Action > Supprimer.
- Contrôle : sur les journaux, le champ « compte en ligne » est vide, et tous vos relevés sont toujours là.
Conservez en revanche une éventuelle connexion vierge (sans nom ni fournisseur) créée par un clic malheureux : Odoo la réutilisera au prochain appairage.
Étape 4 — Ré-appairer, un journal à la fois
- Aller au tableau de bord Comptabilité. C’est là que tout se passe : la fiche du journal ne porte aucun bouton de synchronisation.
- Sur la carte du journal, menu ⋮ > Connect bank.
- Choisir l’établissement, s’authentifier auprès de la banque. Prévoir le second facteur (SMS, application) : cette étape est obligatoirement manuelle.
- À l’écran d’appairage, vérifier que le compte se rattache au journal existant. Si un journal neuf apparaît, annuler et revenir à l’étape 2.
- Recommencer pour le journal suivant.
Cas piégeux : deux journaux portant le même IBAN dans deux devises (un compte EUR et un compte USD chez le même établissement). Odoo les départage par la devise du journal — à condition de les traiter séparément et de vérifier chaque appairage.
Vous n’avez pas à choisir la date de reprise : Odoo la repositionne seul sur la date de votre dernière ligne de relevé, ce qui borne d’office le recouvrement.
Étape 5 — Contrôler
- Chaque journal doit afficher l’état connected, et l’icône de rafraîchissement à la place du bouton rouge.
- Comparer le solde de chaque journal au solde réel du compte à la même date.
- Chasser les doublons : dans la vue de rapprochement, roue crantée > Find duplicate transactions.
- Vérifier en priorité les comptes dont le trou est le plus ancien.
Pourquoi les doublons sont un vrai risque ici : le filtre anti-doublon natif compare les identifiants de transaction fournis par la banque. Or une nouvelle connexion régénère ces identifiants. Le garde-fou qui reste est la détection « même montant + même date + même compte » de l’outil ci-dessus. Ne sautez pas ce contrôle.
8. Éviter la récidive
- Après toute restauration ou duplication de base (montée de version, environnement de test, changement d’hébergeur), traitez la question de l’identité de la base avant de rebrancher la synchronisation bancaire.
- Ne laissez jamais deux instances issues du même dump appeler le service en parallèle. Coupez la synchronisation automatique sur celle qui n’est plus la référence, dès le jour de la bascule.
- Surveillez vos journaux bancaires : un compte qui cesse de descendre pendant deux mois se voit immédiatement sur la date de la dernière ligne de relevé, et pas du tout sur le tableau de bord.
- Suivez les dates d’expiration de consentement (DSP2) : tous les 90 à 180 jours selon les banques. Elles n’ont rien à voir avec le problème ci-dessus, mais produisent le même silence.
Pour conclure
Une erreur cryptographique n’est pas forcément un problème cryptographique. Ici, le message parlait de signature, la cause était une base dupliquée, et la marche à suivre dormait dans le fil de discussion depuis six jours. Le réflexe utile n’est pas de cliquer plus fort sur Reconnect : c’est de remonter le fil, d’établir la chronologie, et de relever le mapping avant de supprimer quoi que ce soit.
Une migration Odoo à préparer, une synchronisation bancaire à remettre en route, ou un doute sur l’état de votre parc ? Parlons-en.