Se rendre au contenu

Veille Odoo : trois correctifs, et votre certificat HTTPS

Rapprochement par référence, fichier de prélèvement SEPA, TVA rouverte ; puis les certificats HTTPS qui raccourcissent et comment surveiller le renouvellement d'un Odoo sur site.
16 octobre 2026 par
| Aucun commentaire pour l'instant

Un client règle une facture par virement, la comptable saisit le paiement à la main par une écriture diverse, et le relevé bancaire arrive avec la référence de la facture débarrassée de ses barres obliques. Odoo ne rapproche rien, et la ligne reste dans les suspens. C'est l'un des trois changements que j'ai retenus dans le dépôt odoo/enterprise pour la semaine du vendredi 9 au jeudi 15 octobre 2026. Le conseil d'exploitation qui suit concerne les serveurs hébergés chez vous : un certificat HTTPS qui expire un matin, et un calendrier de durées de validité qui se raccourcit dès l'an prochain.

Trois mises à jour de la semaine

Le rapprochement retrouve la référence d'une écriture de paiement

Le rapprochement automatique compare le libellé d'une ligne de relevé à la référence de paiement des factures, après avoir retiré tout ce qui n'est pas lettre ou chiffre. Jusqu'ici, cette comparaison ne regardait que le champ « référence de paiement » de la facture et ignorait la référence portée par une écriture de paiement saisie à la main, qui n'a souvent que le champ « référence ». Les commits intégrés entre le 13 et le 15 octobre (module account_accountant d'odoo/enterprise, et le commit du module account d'odoo/odoo) font retomber le calcul sur la référence quand la référence de paiement est vide. Le cas décrit dans le message du commit est exactement celui du paragraphe d'ouverture.

Le correctif est présent dans la 20.0, la saas-19.4 et la branche de développement. Il touche le module account d'odoo/odoo, dont la version change : à la mise à jour, une petite migration reconstruit un index sur la table des écritures. Sur une grosse base hébergée chez vous, prévoyez d'appliquer la mise à jour du module en dehors des heures de saisie. Il complète les règles de rapprochement bancaire sans les remplacer.

Le fichier de prélèvement SEPA à nouveau généré depuis les factures clients

Dans la 20.0, un utilisateur sélectionnait plusieurs factures clients, cliquait sur « Payer », choisissait « Prélèvement SEPA » comme mode de paiement, créait les paiements, puis cliquait sur « Générer le fichier ». Odoo répondait « Seuls les paiements sortants peuvent être exportés ». Le commit du 13 octobre supprime cette restriction et rend le bouton de téléchargement visible sur la fiche du paiement pour les modes de paiement qui produisent un fichier (module account_batch_payment d'odoo/enterprise). Il est dans la 20.0 et dans la branche de développement. Le fichier de ce module ne contient pas ce bouton dans la 19.0, donc je ne sais pas dire si l'erreur y existait sous une autre forme, et je ne l'ai pas testé sur une base.

Le circuit complet est décrit dans l'article sur le prélèvement SEPA dans Odoo 19 ; faites le premier essai sur deux ou trois factures.

Rouvrir une déclaration de TVA quand la piste d'audit est restrictive

Dans l'application Comptabilité, remettre une déclaration à zéro supprimait l'écriture de clôture qui lui était liée. Or, quand la société a activé la piste d'audit restrictive, cette suppression est interdite, et la remise à zéro échouait. Le commit (module account_reports d'odoo/enterprise, intégré entre le 13 et le 15 octobre sur la 20.0 et la saas-19.4) appelle désormais la fonction qui supprime l'écriture si c'est permis, l'annule si la piste d'audit la protège, ou la contre-passe si elle ne peut être supprimée. Une déclaration de TVA rouverte après une erreur ne bloque donc plus, et l'historique reste visible.

La 19.0 et les versions intermédiaires 19.2 et 19.3 portent déjà cet appel : le correctif de cette semaine rattrape la 20.0 et la saas-19.4. Rouvrir une déclaration déjà déposée reste une décision comptable : Odoo l'autorise, il ne dit pas s'il faut déposer une déclaration rectificative.

Votre certificat HTTPS ne durera bientôt plus qu'environ deux mois

Un Odoo sur site derrière nginx est servi en HTTPS avec un certificat qu'une personne de l'équipe a obtenu un jour, souvent avec Certbot, puis oublié. Tant que le renouvellement automatique marche, personne n'y pense. Le jour où il s'arrête, les utilisateurs voient une page d'erreur au lieu de l'écran de connexion, et ils ne peuvent pas la contourner si vous avez suivi la recommandation de la documentation d'Odoo d'ajouter l'en-tête HSTS, puisque la norme demande au navigateur de couper la connexion sans proposer de passer outre (RFC 6797, section 8.4). Ce conseil ne concerne que le sur site ; je n'affirme rien sur la gestion du certificat en Online et sur Odoo.sh.

Le calendrier qui se resserre

Deux calendriers distincts convergent. Pour les certificats vendus par les autorités commerciales, le vote SC-081 du CA/Browser Forum, adopté en avril 2025, prévoit une durée maximale qui passe de 398 à 200 jours depuis le 15 mars 2026, puis à 100 jours le 15 mars 2027 et à 47 jours le 15 mars 2029 (le vote sur le site du CA/Browser Forum donne le début et la fin du calendrier ; les paliers intermédiaires, je les tiens de sources secondaires qui concordent). Si votre certificat de domaine est acheté une fois par an, la prochaine facture ne couvrira donc plus douze mois.

Let's Encrypt, de son côté, délivre aujourd'hui des certificats de 90 jours. Son annonce de décembre 2025 prévoit des certificats de 64 jours par défaut à partir du 10 février 2027, puis de 45 jours à partir du 16 février 2028, et précise qu'un renouvellement programmé en dur à 60 jours ne suffira plus (l'annonce de Let's Encrypt). Certbot n'est pas concerné de la même façon : sa documentation indique qu'il renouvelle quand il reste moins d'un tiers de la durée de vie, ce qui fait environ 21 jours avant l'échéance pour un certificat de 64 jours (calcul de ma part). Sont exposés ceux qui ont écrit leur propre script avec un nombre de jours fixe, ou qui renouvellent à la main.

Autre changement qui explique pourquoi on découvre les pannes tard : Let's Encrypt n'envoie plus d'email d'avertissement avant l'expiration depuis le 4 juin 2025 (l'avis de fin du service). Si votre seul filet de sécurité était cet email, il n'existe plus depuis seize mois.

Avant d'appliquer ces conseils : testez chaque manipulation sur une copie de votre base ou sur un serveur de test, jamais directement en production. Ces conseils sont rédigés sans connaître votre configuration et peuvent ne pas s'appliquer tels quels chez vous. Nexelans ne peut pas être tenue responsable des conséquences d'une manipulation faite sans ces précautions.

Vérifier que le renouvellement tourne vraiment

Trois vérifications prennent dix minutes sur le serveur qui porte nginx.

  1. Listez les certificats que Certbot connaît avec certbot certificates : la sortie indique pour chacun la date d'expiration et le nombre de jours restants.
  2. Cherchez la tâche planifiée. Certbot l'installe en général sous forme de minuterie systemd ou de ligne dans la crontab ; systemctl list-timers montre la première, cat /etc/cron.d/certbot la seconde. La documentation de Certbot précise que la commande certbot renew est lancée périodiquement et qu'elle ne renouvelle que ce qui approche de l'échéance.
  3. Simulez : certbot renew --dry-run exécute un renouvellement de test sur l'environnement de test de Let's Encrypt, sans toucher aux vrais certificats.

Un renouvellement réussi ne sert à rien si nginx continue de servir l'ancien fichier en mémoire. Selon la façon dont le certificat a été obtenu, il faut peut-être faire recharger nginx après chaque renouvellement : Certbot exécute pour cela les scripts placés dans /etc/letsencrypt/renewal-hooks/deploy/, uniquement quand un certificat vient d'être renouvelé. Un script d'une ligne qui lance systemctl reload nginx suffit, à adapter à votre système.

Une alerte qui ne dépend pas de Certbot

Le contrôle le plus fiable regarde ce que voient les utilisateurs, pas ce que pense Certbot. La commande suivante interroge le serveur de l'extérieur et affiche la date d'expiration réellement servie :

echo | openssl s_client -connect erp.exemple.fr:443 -servername erp.exemple.fr 2>/dev/null | openssl x509 -noout -enddate

Pour en faire une alerte, l'option -checkend de openssl x509 renvoie un code d'erreur si le certificat expire dans le nombre de secondes indiqué (1 209 600 pour quatorze jours). Placez ce test dans la supervision que vous avez déjà, ou dans une tâche cron qui envoie un email, et remplacez le nom de domaine par le vôtre. Quatorze jours de préavis me semblent raisonnables pour des certificats de 64 jours.

Si votre certificat est acheté et installé à la main, la seule mesure utile est de mettre l'échéance dans l'agenda de deux personnes et de demander à votre fournisseur la durée réelle du prochain. Un certificat émis avant le 15 mars 2026 garde sa durée jusqu'à son terme ; c'est le renouvellement qui vous fera découvrir les 200 jours. Le contrat Odoo Enterprise, avec les limites de son support, ne couvre pas le nginx d'un serveur que vous administrez vous-même.

Sources

16 octobre 2026
Partager cet article
Étiquettes
Développement Hébergement & sécurité Nouveautés & versions Odoo
Archive
Se connecter pour laisser un commentaire.