SECII

Une migration Odoo n’est pas une mise à jour. Entre la version 16 et la version 19, Odoo a supprimé des pans entiers de son interface de programmation : la syntaxe conditionnelle des vues, la balise qui déclarait une liste, la méthode qui donnait son nom affiché à un enregistrement, l’ancien cadre JavaScript. Un module qui les utilise ne se dégrade pas — il ne se charge pas.

Le parc de SECII comptait vingt-deux modules sur mesure, et cent cinq occurrences de ces syntaxes disparues dans les seuls fichiers de vue. Le module le plus critique — un filtre par commercial sur le grand livre et la balance âgée — reposait à la fois sur l’ancien cadre JavaScript et sur une copie du moteur de rapports comptables, désynchronisée du standard depuis longtemps.

Et un piège attendait plus loin : le rôle métier « Commercial », avec son groupe, ses vingt-deux règles d’accès et ses trois règles d’enregistrement, appartenait à un module destiné à être remplacé. Le désinstaller aurait effacé le rôle par cascade, et avec lui les habilitations de toute une équipe.

Le travail a commencé par un audit écrit avant la première ligne de code : une fiche par module — ce qu’il fait, ce qu’il contient, ce qui casse en v19, et un verdict. Migrer, réécrire, ou abandonner. De cet inventaire est sorti un ordre de passage en cinq couches, dicté par les dépendances entre modules : le socle d’abord, les rapports ensuite, les modules qui en dépendent après, et le plus enchevêtré en dernier.

Le principe de la première phase était volontairement conservateur : portage un pour un, aucune fusion. Une migration qui refactorise en même temps qu’elle migre ne permet plus de savoir ce qui a cassé. Les regroupements identifiés pendant l’audit ont été notés comme décisions différées, pas exécutés au passage.

Chaque module était installé sur une base jetable avant d’aller plus loin — jamais sur la base de production ni sur sa copie de recette.

Vingt-deux modules v16 devenus trente en v19.

Dix-neuf ont gardé leur nom et ont été adaptés : syntaxes de vue disparues corrigées jusqu’à la dernière occurrence, méthodes supprimées remplacées, widget JavaScript du filtre commercial réécrit dans le cadre moderne.

Trois ont été remplacés par des modules reconçus — la certification fiscale électronique, le suivi des dépenses scindé en deux, et surtout le module de droits d’accès. Les originaux sont conservés à l’identique dans un dossier de garde plutôt que supprimés.

Sept sont entièrement nouveaux : miroir comptable inter-sociétés, dissociation de partenaire, raccourcis de sélection de société, blocage de vente en rupture, seuil de prix, lien d’acompte sur achat.

Les scripts de migration de données sont la partie invisible et la plus délicate. Celui qui sauve le rôle « Commercial » détache en SQL direct, hors ORM, le groupe et ses règles de leur module d’origine avant sa désinstallation — pour qu’ils survivent à la cascade de suppression. Le rôle est ensuite conservé tel quel, plutôt que reconstruit dans le nouveau moteur : le remapper aurait donné à des commerciaux des droits d’administration de l’outil. Un second script renomme l’identité technique du module de certification fiscale et recopie ses paramètres par société, avec une neutralisation des identifiants lors des clonages de la production vers la recette.

Le nouveau moteur de droits est le gain fonctionnel du projet. Là où l’ancien définissait un rôle unique en XML statique, le nouveau accorde des dérogations par utilisateur sur cinq axes — l’enregistrement, le champ, l’onglet, la vue et le bouton — chacune limitable à une société, et chaque modification journalisée sur la fiche de l’utilisateur concerné.

Les cent cinq occurrences de syntaxes supprimées sont tombées à zéro. La méthode de nommage obsolète a disparu du parc. Le widget JavaScript du module le plus à risque tourne dans le cadre moderne. Le rôle métier a survécu au remplacement de son module d’origine, sans réattribution manuelle des habilitations.

Au passage, l’hygiène du parc a nettement progressé : la licence, déclarée dans quatre manifestes sur dix en v16, l’est dans neuf sur dix en v19, et les numéros de version suivent enfin une convention unique. Le dépôt v19 ne dépend d’aucun module tiers.