Certificat officiel Odoo — Silver Partner · émis le 10 juillet 2025
Changer de version d'Odoo, ce n'est pas cocher une case un vendredi soir. C'est déplacer vos données, vos modules développés sur mesure et vos habitudes de travail d'un socle vers un autre, sans casser ce qui tourne. Depuis Tunis, notre expertise d'intégrateur Odoo nous a menés sur des sauts de version longs comme sur des reprises complètes depuis d'autres logiciels.
Odoo évolue vite, et une base restée plusieurs versions en arrière a accumulé des écarts que rien n'absorbe automatiquement. Les modèles de données changent de nom, des champs disparaissent, des fonctionnalités partent dans d'autres applications, et vos modules custom cessent simplement de se charger. Une montée de version se traite comme un projet : on inventorie l'existant, on décide ce qu'on garde, on refait ce qui doit être refait, on teste sur une copie. Chez TSS, nous avons conduit la migration depuis Odoo v8 jusqu'à Odoo v19 — donc oui, les grands sauts de version, nous savons ce que ça demande.
Beaucoup d'entreprises n'arrivent pas d'une vieille version d'Odoo mais d'un logiciel de gestion arrivé en bout de course, parfois d'un fichier Excel devenu la mémoire de la société. Là, il n'y a aucun outil magique : il faut extraire, nettoyer, faire correspondre les structures et charger. Le travail utile est en amont, dans le nettoyage — les doublons clients, les articles fantômes et les soldes qui ne tombent pas juste vous suivront dans Odoo si personne ne les traite. Nous préférons dire clairement ce qui est reprenable et ce qui ne l'est pas plutôt que de tout importer et de découvrir le problème après le démarrage.
Si votre Odoo n'avait que du standard, une montée de version resterait un exercice technique classique. Ce qui coûte du temps, ce sont les développements accumulés au fil des années, souvent sans documentation, parfois écrits par quelqu'un qui n'est plus là. Chaque module doit être relu, réécrit pour la version cible, puis confronté au standard : il arrive qu'une fonctionnalité développée sur mesure il y a des années soit désormais couverte nativement par Odoo. C'est le bon moment pour alléger, pas pour recopier une dette technique dans une version neuve.
Une migration se juge le lundi matin, quand vos équipes rouvrent Odoo. Avant d'y arriver, vos utilisateurs testent sur la base migrée avec leurs vrais dossiers, leurs vraies factures, leurs vrais bulletins de paie — c'est le seul moyen de faire remonter ce qu'aucun test technique ne verra. La bascule se prépare avec un créneau défini, une procédure écrite et un retour arrière possible. Ensuite, le sujet n'est plus la migration mais la vie quotidienne du système, et c'est là qu'intervient notre helpdesk.
Honnêtement, cela dépend du périmètre : nombre de modules, volume de données et code spécifique à reprendre. Le déroulé, lui, est toujours le même : audit de l'existant, migration technique sur un environnement de test, reprise des données, recette avec vos équipes, puis bascule en production. Un dossier simple se compte en semaines ; une base ancienne avec beaucoup de développements sur mesure se compte en mois. C'est l'audit initial qui permet de vous donner un planning réaliste avant de vous engager.
Oui, même très ancienne. Nous accompagnons par exemple TSS sur un passage d'Odoo 8 vers Odoo 19, soit onze versions d'écart. Ce type de projet se traite différemment d'une montée de version classique : on audite d'abord la base et le code, on identifie ce qui doit être réécrit, puis on migre par étapes sur un environnement de test. Plus la version est ancienne, plus la phase d'audit compte : c'est elle qui évite les mauvaises surprises en cours de route.
Ils sont passés en revue un par un pendant l'audit. Trois cas de figure : certains deviennent inutiles, car la fonction existe désormais en standard dans Odoo ; d'autres sont adaptés à la nouvelle version ; les plus anciens doivent être réécrits, le code d'une vieille version ne fonctionnant pas tel quel sur une récente. C'est souvent l'occasion de faire le tri : moins de code spécifique, c'est un Odoo plus simple à maintenir et des montées de version futures moins lourdes.
Oui, c'est un cas fréquent en Tunisie. On récupère vos données de référence — clients, fournisseurs, articles, stocks, balances comptables — depuis l'export de votre logiciel actuel ou vos fichiers Excel, puis on les structure pour Odoo. On ne reprend pas tout l'historique aveuglément : on définit ensemble ce qui mérite vraiment d'être conservé. Le plan comptable tunisien et les paramétrages locaux, comme la TVA ou le timbre fiscal, sont mis en place dès le départ.
Notre méthode est justement conçue pour l'éviter : nous travaillons toujours sur une copie de votre base, jamais directement sur la production. Votre système actuel continue de tourner intact pendant toute la durée du projet. Les données migrées — soldes comptables, encours, stocks — sont ensuite contrôlées, et vous les validez lors de la recette. La bascule n'a lieu qu'après votre feu vert, et l'ancienne base est conservée en sauvegarde après la mise en production.
Non, pas des jours entiers. L'essentiel du travail se fait en parallèle de votre activité, sur un environnement de test qui ne touche pas votre système actuel. Seule la bascule finale demande un gel court des saisies, le temps de transférer les dernières données et de rediriger les utilisateurs. On la planifie sur un créneau creux — un week-end en général — pour que vos équipes retrouvent le nouvel Odoo au retour, sans coupure pendant les heures de travail.