Implémentation Odoo : les étapes d'un projet réussi

Cas réel · Distribution alimentaire
                                 
 
Si on vous parle d'Ogust Food, c'est parce que ce projet illustre exactement pourquoi l'ordre des cycles n'est pas négociable. Sur le papier, le besoin le plus excitant était la logistique : gestion des stocks et intégration Chronofresh pour les expéditions en froid. Beaucoup d'intégrateurs auraient attaqué par là. Nous avons commencé par la gestion commerciale, la brique la plus « banale ». Et c'est elle qui a révélé le vrai chantier : en paramétrant les produits, on s'est aperçu qu'Ogust ne vend pas des sauces à l'unité mais des cartons et des boîtes. Tout le catalogue a dû être restructuré autour de ce packaging réel.

Voilà le point : si nous avions commencé par le stock, chaque mouvement, chaque inventaire, chaque expédition Chronofresh aurait été calculé sur une unité de vente fausse. Il aurait fallu tout défaire. C'est le cycle « simple » qui a rendu les cycles « complexes » possibles : d'abord un référentiel produit juste, ensuite les stocks qui s'appuient dessus, et seulement alors les intégrations API. La leçon pour votre projet : la brique simple n'est pas un échauffement, c'est la fondation de tout ce qui suit.

Cas réel · Éclairage professionnel B2B
                                      
 
L'exemple de Voltra Lighting montre pourquoi « standard d'abord » n'est pas un dogme de fainéant, mais une méthode de conception. Cette société équipe l'hôtellerie et travaille avec de grands comptes : elle avait donc de vrais besoins spécifiques de pilotage, des tableaux de bord et des champs sur mesure pour suivre ses clients B2B. La tentation aurait été de les construire dès le premier jour, en atelier, sur la base de ce qu'on imaginait.

Nous avons fait l'inverse : plusieurs semaines de flux 100 % standard avec la responsable des opérations. Et c'est l'usage réel qui a dessiné le sur-mesure : les informations dont elle avait réellement besoin pour piloter ses comptes ne sont apparues qu'en travaillant dans l'outil, pas en réunion. Les tableaux de bord qu'on a construits ensuite reposaient sur des besoins constatés, pas supposés. Si nous les avions développés au jour 1, nous aurions codé des hypothèses, et il aurait fallu les refaire. Le spécifique arrive en second, non pas parce qu'il est moins important, mais parce que c'est le standard qui vous apprend de quel spécifique vous avez vraiment besoin.

Cas réel · Industrie, Vénissieux
 
Pourquoi vous raconter la migration comptable de Solution Industrie ? Parce que c'est le cas d'école de ce que coûte réellement « récupérer l'historique ». L'entreprise venait de Ciel, un logiciel ancien, avec l'hypothèse de départ de tout reprendre. La réalité : dans un vieux logiciel, les données ne sont pas rangées là où on les attend, et il n'existe aucun outil miracle qui les aspire. Nous passons par les utilitaires d'export d'origine, comme tout le monde. Quand ils sont limités, une seule extraction propre peut coûter des demi-journées, parfois des journées entières de travail.

C'est exactement pour cette raison que ce chapitre vous dit d'importer l'utile et pas tout l'historique : chaque année d'archives ajoutée se paie en jours de nettoyage qui retardent votre Go-Live. Et c'est aussi pourquoi beaucoup d'intégrateurs refusent tout simplement l'opération : elle est longue et peu rentable pour eux. Nous, nous la prenons en charge de bout en bout quand le client ne peut pas fournir ses fichiers sources, mais en connaissance de cause et sur un périmètre arbitré ensemble. La transparence sur ce coût fait partie du cadrage, pas des mauvaises surprises.

Retour de terrain · Les projets qu'on rattrape
Ce filtre des demandes, nous ne l'appliquons pas par principe : nous l'appliquons parce que nous avons vu ce qui arrive sans lui. Une partie de notre activité consiste à reprendre des bases Odoo sur-customisées par le passé : des sociétés qui ont dit oui à chaque idée dès le premier jour, un champ par-ci, une automatisation par-là. Sur le moment, chaque ajout semble être un progrès. C'est comme l'électricité d'un appartement : chaque fil tiré donne une lumière de plus, jusqu'au jour où le tableau est illisible et où il faut tout arracher pour recâbler proprement, sous peine d'incendie.

Avec Odoo, l'incendie s'appelle : mises à jour impossibles, flux que plus personne ne comprend, et une facture de « décustomisation » qui dépasse souvent le coût du projet initial bien mené. Quand nous refusons une demande en cours d'implémentation, ce n'est donc pas un manque de flexibilité : c'est ce qui vous évite de nous payer, dans deux ans, pour effacer ce qu'on aurait accepté aujourd'hui.

Notre méthode, concrètement
Pourquoi ce rituel précis plutôt que des « tests de recette » en fin de projet ? Parce qu'une anomalie découverte en semaine 3 coûte un ajustement dans la semaine ; la même anomalie découverte au Go-Live coûte un arrêt d'activité. Concrètement : dès le kick-off, on valide ensemble un processus métier de A à Z, qui fait quoi, à quel moment, très précisément. Puis nous ouvrons une base de test dédiée (sur nos serveurs ou ceux d'Odoo) à laquelle vos équipes accèdent librement, et chaque semaine, un rendez-vous de 2 heures : le client rejoue ses scénarios réels, on constate ensemble ce qui passe et ce qui bloque, on ajuste dans la semaine, et on rejoue les mêmes scénarios la semaine suivante pour mesurer le chemin parcouru.

Le jour du Go-Live, les flux ont donc déjà été exécutés des dizaines de fois par les personnes qui les utiliseront. C'est une méthode simple sur le papier, exigeante en réalité : elle demande de la rigueur des deux côtés, expert comme client. Mais c'est précisément ce travail hebdomadaire qui transforme la bascule en formalité plutôt qu'en saut dans le vide.