Quentin Mathonet

Quentin Mathonet

J’ai d’abord connu Odoo de l’intérieur pendant plus de dix ans, à une période où sa promesse était très claire : permettre aux TPE et PME d’accéder à un ERP complet, intégré et moderne, sans les coûts, les délais ou la complexité traditionnellement associés aux grandes plateformes du marché. L’ambition n’était pas simplement de remplacer un logiciel comptable ou quelques fichiers Excel, mais de proposer un environnement unifié couvrant les fonctions essentielles de l’entreprise : ventes, achats, stocks, finance, production, projets, RH ou encore e-commerce.

Cette proposition reste très pertinente aujourd’hui. Mais le marché et la maturité de la solution ont évolué. On voit de plus en plus d’entreprises de taille intermédiaire, mais également des groupes plus structurés, s’intéresser à Odoo pour remplacer des systèmes historiques devenus coûteux, fragmentés ou difficiles à faire évoluer. Elles recherchent davantage de flexibilité, une meilleure intégration entre les départements, une capacité d’adaptation plus rapide à leur croissance et un coût total de possession plus maîtrisé.

Ce changement élargit les opportunités, mais il élève aussi fortement le niveau d’exigence. Un projet ERP plus large ne se résume jamais à déployer plus d’applications ou à ajouter des utilisateurs. Il implique souvent plusieurs entités juridiques, des contraintes de localisation, des flux d’inventaire et de production plus sophistiqués, des exigences de reporting financier, des processus de validation plus formels et un environnement applicatif existant qu’il faut analyser avec pragmatisme. La question devient alors moins « Peut-on installer le logiciel ? », mais plutôt « Quel modèle opérationnel voulons-nous construire, et quelles décisions l’organisation est-elle prête à prendre pour y parvenir ? »

Passer du côté de l’intégration, chez Eezee, m’a précisément permis de voir ce point avec plus de recul. Chez l’éditeur, on porte naturellement une attention forte au produit, à sa roadmap, à ses fonctionnalités standard et à une méthodologie qui doit rester reproductible à grande échelle. Du côté de l’intégration, on est beaucoup plus proche des réalités quotidiennes de l’entreprise : les contraintes métiers, la qualité des données, les habitudes de travail, les exceptions accumulées avec le temps, les systèmes existants, mais aussi les équilibres humains et décisionnels qui influencent directement le projet.

Cette position donne aussi une responsabilité particulière : faire le lien entre les capacités du produit et la réalité opérationnelle du client. Cela peut passer par une verticalisation de certains processus métier ou par des intégrations avec des systèmes qui doivent légitimement rester en place. Mais il faut le faire avec discipline. L’objectif n’est pas de recréer l’ancien système dans un nouvel outil, ni de développer une réponse spécifique à chaque demande. Il est de conserver le standard partout où il apporte de la simplicité, de n’adapter que ce qui correspond à une exigence réellement différenciante ou non négociable, et de connecter uniquement les systèmes nécessaires au bon fonctionnement du flux opérationnel.

Lorsqu’une transformation ne produit pas les résultats attendus, je ne regarde donc pas d’abord le produit, la méthode ou l’organisation comme s’il fallait choisir un seul responsable. Je commence par analyser l’alignement entre les trois. Un produit pertinent peut être mal positionné ou vendu avec un périmètre irréaliste. Une méthodologie solide peut échouer si les décisions sont retardées, si les priorités changent constamment ou si le projet avance sans sponsors réellement engagés. Et une organisation peut être très motivée, mais manquer de processus stabilisés, de référentiels de données fiables ou de disponibilité côté métiers.

La première étape consiste à vérifier si le projet a été correctement cadré avant même son lancement. A-t-on compris le secteur, les contraintes réglementaires, les impératifs financiers et les processus qui font réellement tourner l’entreprise ? A-t-on distingué les besoins essentiels des préférences héritées de l’ancien système ? A-t-on été transparent sur les compromis à faire entre périmètre, budget, délais et niveau de personnalisation ?

Ensuite, il faut examiner la méthode d’implémentation. Un projet ERP a besoin d’une gouvernance claire, d’un sponsor capable d’arbitrer, d’une équipe client disponible, de key users responsabilisés et d’un calendrier réaliste. Il doit aussi intégrer des phases structurées d’analyse, de conception, de paramétrage, de reprise de données, de tests, de formation, de validation et d’accompagnement après mise en production. Une mise en œuvre réussie ne dépend pas uniquement de la vitesse de livraison ; elle dépend de la qualité de ce qui est adopté et maintenu après le go-live.

Enfin — et c’est souvent le facteur le plus sous-estimé côté client, mais aussi l’explication la plus facile côté intégrateur — je regarde l’organisation elle-même. Le changement ne peut pas être porté uniquement par l’équipe projet ou par l’intégrateur. Il faut comprendre qui maîtrise réellement les processus, qui est susceptible de les faire évoluer, quelles personnes doivent être associées aux décisions et où se situent les résistances légitimes ou les craintes. La conduite du changement commence bien avant les formations : elle commence dès le moment où l’on explique pourquoi certains processus doivent évoluer, ce que les équipes y gagnent et ce que l’on attend concrètement d’elles. Les impliquer le plus tôt et le plus concrètement possible dans le projet est essentiel au succès de l’implémentation.

Pour moi, un ERP est un levier de transformation, mais il ne transforme pas une entreprise à lui seul. Un ERP oblige l’entreprise à voir ce qu’elle pouvait auparavant contourner : les règles non écrites, les données peu fiables et la dépendance à quelques personnes. La réussite dépend donc de la qualité du produit, de la rigueur de la méthode et de la maturité de l’organisation, mais surtout de la cohérence entre ces trois éléments.

Quentin Mathonet

Un ERP ne transforme pas une entreprise par lui-même. On peut dire qu’il constitue plutôt un révélateur et un accélérateur. Il révèle ce qui n’a jamais été suffisamment structuré : des processus qui reposent sur des habitudes plutôt que sur des règles claires, des données contradictoires entre départements, des validations informelles, une dépendance à quelques personnes clés, ou encore des exceptions devenues la norme au fil de la croissance.

Dans beaucoup d’entreprises, les dysfonctionnements restent longtemps invisibles parce que les équipes compensent au quotidien : avec des fichiers Excel, des échanges WhatsApp, des validations verbales, des tableaux personnels ou une connaissance historique détenue par quelques collaborateurs. Tant que l’activité reste à une certaine échelle, cela peut fonctionner. Mais lorsqu’on introduit un ERP, l’organisation doit formaliser ses règles : qui crée un article, qui valide une commande, comment un prix est déterminé, à quel moment un stock est disponible, quelle donnée fait foi, qui peut modifier une écriture ou engager une dépense. C’est à ce moment-là que les zones grises apparaissent.

L’ERP ne crée donc pas ces problèmes, il les rend difficiles à contourner. Et c’est précisément là que commence la transformation. Si l’entreprise accepte de remettre en question certains processus, de clarifier les rôles et de prendre des décisions, l’ERP devient un outil structurant. Si elle cherche uniquement à reproduire exactement l’ancien fonctionnement, y compris ses exceptions et ses contournements, elle risque de livrer techniquement un projet dans les délais tout en échouant sur le plan opérationnel.

La nuance est essentielle. Un projet peut être considéré comme « livré » parce que les modules ont été configurés, les données migrées et les utilisateurs formés. Mais il n’est réussi que lorsque les équipes utilisent réellement le système comme référence, que les processus fonctionnent sans dépendre de fichiers parallèles et que la direction peut prendre des décisions à partir de données plus fiables, plus cohérentes et plus accessibles.

C’est pourquoi l’adoption ne doit jamais être traitée comme une dernière étape, limitée à quelques sessions de formation avant la mise en production. Elle doit être intégrée dès le début du projet. Les key users ne doivent pas découvrir la solution lors de la formation finale. Ils doivent contribuer aux choix, tester les flux et devenir les relais du projet auprès de leurs équipes. Lorsqu’ils comprennent le sens des changements et participent aux décisions, l’adoption devient beaucoup plus naturelle.

À mon sens, lorsqu’un intégrateur estime qu’un client n’est pas encore prêt, son rôle est d’être transparent, de challenger et de protéger le projet, y compris lorsque cela implique de ralentir, de réduire le périmètre ou de remettre en cause certaines demandes. Un intégrateur ne doit pas se substituer à la direction du client ni prendre les décisions internes à sa place. En revanche, il a la responsabilité de signaler clairement les risques : absence de sponsor, indisponibilité des équipes métier, décisions non tranchées, données insuffisamment fiables, périmètre trop large, attentes irréalistes ou volonté de préserver toutes les anciennes exceptions.

Dans certains cas, la bonne décision est de démarrer par une phase de cadrage plus approfondie, un travail de nettoyage des données, une clarification des rôles et responsabilités, ou un déploiement progressif par flux, par département, par filiale ou par pays. Reporter un go-live n’est pas nécessairement un échec : cela peut être une décision de gouvernance responsable, si elle évite d’installer durablement un outil mal compris ou rejeté par les équipes.

L’intégrateur doit donc aller jusqu’au point où il rend les conséquences visibles et propose une trajectoire réaliste. Il doit pouvoir dire : « Dans ces conditions, voici ce qui est faisable, voici les risques, voici les décisions à prendre et voici ce qu’il faudrait décaler ou simplifier. » Mais il doit aussi respecter une limite : il ne peut pas vouloir changer l’organisation à la place de ses dirigeants. La transformation doit être portée par le client lui-même, avec un sponsor qui assume les arbitrages et donne une direction claire.

En définitive, un ERP devient transformant lorsqu’il oblige l’entreprise à passer de pratiques individuelles et de connaissances implicites à des processus partagés, des données de référence et des responsabilités explicites. La technologie fournit le cadre, l’intégrateur apporte la méthode et le recul, mais l’organisation doit accepter de changer pour que le projet produise réellement ses effets.

Quentin Mathonet

Je pars d’un principe tout simple : tout ce qui est ancien n’est pas forcément inutile, mais tout ce qui est ancien n’est pas non plus un avantage compétitif. Dans les projets ERP, il faut en effet se méfier d’une confusion fréquente entre ce qui différencie réellement l’entreprise et ce que les équipes ont simplement appris à contourner ou à maîtriser avec le temps.

Une habitude peut être très défendue parce qu’elle rassure, parce qu’elle donne un sentiment de contrôle ou parce qu’elle est portée par une personne clé. Mais cela ne signifie pas qu’elle crée de la valeur. Par exemple, une validation manuelle supplémentaire, un tableau Excel parallèle ou une succession d’exceptions commerciales peut avoir été justifié à un moment donné. Mais avec la croissance de l’entreprise, ce même mécanisme peut devenir une source de lenteur, d’erreurs, de dépendance à certaines personnes et de manque de visibilité pour la direction.

À l’inverse, certaines spécificités sont réellement structurantes. Elles peuvent découler d’un modèle commercial particulier, d’un savoir-faire de production, d’une exigence réglementaire, d’une logique de prix ou de service qui distingue l’entreprise sur son marché, ou encore d’une contrainte propre à son secteur. Dans ce cas, chercher à tout faire entrer dans un standard générique peut affaiblir ce qui fait précisément la valeur de l’organisation.

Pour faire la différence, nous examinons d’abord la contribution réelle du processus à la promesse faite au client, à la qualité du produit ou du service, à la maîtrise d’un risque réglementaire ou financier ou encore à la protection d’une marge. Nous vérifions aussi s’il resterait pertinent si l’entreprise doublait de taille, ouvrait une nouvelle filiale ou renouvelait une partie importante de ses équipes. Enfin, un processus réellement structurant doit pouvoir être expliqué, mesuré et transmis. S’il repose surtout sur des connaissances implicites, il s’agit souvent davantage d’une fragilité que d’un avantage compétitif.

Si plusieurs de ces critères sont réunis, la demande mérite d’être examinée comme une différenciation possible. Mais même dans ce cas, la personnalisation n’est pas automatiquement la bonne réponse. Il faut d’abord voir si le standard peut répondre au besoin avec une configuration adaptée, une discipline de processus ou une évolution d’organisation. On ne doit développer ou intégrer que lorsqu’il existe un écart réel, durable et significatif entre le besoin métier et les possibilités standard de la solution.

C’est là que je place la frontière : une personnalisation utile renforce une capacité distinctive, améliore la qualité ou la vitesse d’exécution, répond à une obligation non négociable ou enlève une friction réelle sans créer de nouvelle dépendance. À l’inverse, elle devient un transfert de complexité lorsqu’elle sert surtout à préserver une ancienne manière de travailler, à éviter un arbitrage interne ou à maintenir une exception qui n’est ni documentée, ni mesurable, ni capable de supporter la croissance.

Il faut également considérer le coût complet d’une personnalisation, et pas seulement son coût initial. Chaque développement doit être testé, maintenu, documenté, sécurisé et rendu compatible avec les futures évolutions de la plateforme. Trop de développements spécifiques peuvent ralentir l’adoption, rendre l’outil plus difficile à comprendre, compliquer les upgrades de version et recréer la rigidité que l’entreprise cherchait précisément à quitter.

Je préfère donc une logique en trois niveaux. D’abord, standardiser ce qui ne différencie pas l’entreprise : les processus administratifs, les données de base, les validations simples et les flux communs doivent être aussi clairs et homogènes que possible. Ensuite, configurer lorsque le standard permet de refléter le besoin sans créer de dette technique. Enfin, personnaliser de manière ciblée uniquement ce qui porte une valeur métier durable et démontrable.

Cette approche ne consiste pas à imposer un ERP au client. Elle consiste à l’aider à distinguer son identité opérationnelle de son héritage opérationnel. Un bon projet ne doit pas effacer ce qui rend une entreprise performante, il doit éliminer ce qui la rend difficile à piloter, à faire évoluer et à transmettre.

Le rôle de l’intégrateur est donc de challenger avec respect. Il doit pouvoir dire : « Nous pouvons techniquement reproduire ce fonctionnement, mais avant de le faire, assurons-nous qu’il répond toujours à un besoin stratégique et qu’il ne représente pas simplement une contrainte historique. » C’est souvent dans cette conversation que se joue la qualité d’une transformation ERP. En résumé, la bonne personnalisation ne reproduit pas la complexité : elle protège une différence utile. Tout le reste doit être simplifié, standardisé ou remis en question.

Quentin Mathonet

L’Arabie saoudite et les Émirats arabes unis sont proches géographiquement, étroitement liés sur le plan économique et portés par des ambitions similaires de digitalisation, de croissance et de professionnalisation des entreprises. Pourtant, dans un projet ERP, les traiter comme un marché unique serait une erreur. Les grands principes restent comparables, mais le contexte dans lequel l’entreprise prend ses décisions, organise le changement et adopte de nouveaux processus peut être très différent.

Aux Émirats, nous intervenons fréquemment auprès d’entreprises qui ont évolué dans un environnement très international : équipes multiculturelles, actionnariat ou clients étrangers, opérations réparties dans plusieurs pays, et exposition de longue date à des standards internationaux de gestion et de gouvernance. Cela peut faciliter l’acceptation d’une logique de standardisation des processus et d’un modèle opérationnel commun entre plusieurs entités. Beaucoup de ces entreprises ont aussi grandi rapidement en ajoutant successivement des outils, des fichiers Excel et des processus locaux. Leur besoin ERP consiste alors souvent à réunifier l’information, consolider les données, réduire les opérations parallèles et disposer d’une vision plus fiable de l’ensemble de leur activité.

En Arabie saoudite, nous observons une dynamique de transformation particulièrement forte et rapide. Les ambitions de croissance, de diversification, d’industrialisation et de conformité conduisent de nombreuses organisations à revoir à la fois leurs systèmes et leur mode de fonctionnement. Les projets ERP y sont souvent perçus comme une infrastructure stratégique : non seulement pour automatiser les opérations, mais aussi pour accompagner l’expansion, renforcer la gouvernance, structurer les données et répondre à un environnement réglementaire de plus en plus exigeant. En Arabie saoudite, la conformité, notamment autour de ZATCA et de la facturation électronique, est souvent un point structurant du projet dès le cadrage.

Cela ne veut pas dire que les Émirats sont systématiquement plus matures, ni que l’Arabie saoudite est un marché moins international. Ce serait une simplification. Les Émirats ont une exposition historiquement forte à des modèles de gestion internationaux, mais l’Arabie saoudite attire elle aussi de nombreux talents internationaux et développe rapidement ses propres compétences, ses organisations et ses standards. Nous voyons d’ailleurs de plus en plus de circulation de talents, de pratiques et d’expertise entre les deux pays, ainsi qu’entre le Royaume et les marchés internationaux. La différence est davantage une question de trajectoire, de rythme de transformation et de priorités organisationnelles qu’un niveau absolu de maturité.

Cette nuance apparaît aussi dans la manière d’aborder le go-live. Aux Émirats, nous constatons régulièrement qu’une mise en production progressive — par flux, département, entité juridique ou pays — est bien acceptée. Elle permet de réduire le risque, de tester les processus dans des conditions réelles, d’intégrer les retours des utilisateurs et de construire l’adoption étape par étape. Cette approche est particulièrement pertinente lorsque le groupe compte plusieurs entités, que les processus ne sont pas entièrement homogènes ou que les données nécessitent un travail de fiabilisation progressif.

En Arabie saoudite, certaines organisations préfèrent une bascule plus globale, de type big bang. Elles y voient une manière de mettre rapidement tout le monde sur un modèle unique, d’éviter une trop longue coexistence entre l’ancien et le nouveau système, et de donner au projet une impulsion claire à l’échelle du groupe. Cette préférence ne doit toutefois pas être interprétée comme une règle nationale. Un big bang peut être judicieux lorsque les flux sont fortement interconnectés, que le périmètre est maîtrisé, que les données sont prêtes et que le sponsor ainsi que les équipes métiers sont réellement mobilisés. À l’inverse, il devient dangereux lorsqu’il sert à masquer un manque de préparation ou des décisions non tranchées.

À mes yeux, il n’existe donc pas de méthodologie uniforme au sens d’un déroulé identique pour tous les pays et toutes les entreprises du Moyen-Orient. Il existe en revanche une discipline commune : un diagnostic sérieux, une vision cible, un périmètre priorisé, une gouvernance claire, des key users responsabilisés, une stratégie de données, des tests approfondis, une conduite du changement et un accompagnement solide après la mise en production.

Ce qui varie, c’est l’exécution de ce cadre : le rythme, le séquencement, le degré de localisation, la langue de travail, la structure de décision, les exigences de conformité et les leviers d’adhésion des équipes. Une méthodologie régionale efficace doit être suffisamment structurée pour garantir la qualité et capitaliser sur les meilleures pratiques, mais suffisamment flexible pour respecter la réalité locale de chaque client.

En résumé, on peut standardiser la rigueur d’exécution à l’échelle régionale, mais on ne peut pas standardiser aveuglément le contexte dans lequel une entreprise doit changer.

Quentin Mathonet

Il existe effectivement un point de bascule, mais il ne correspond ni à un montant de chiffre d’affaires ni à un effectif précis. Deux entreprises de taille comparable peuvent avoir des besoins totalement différents selon leur secteur, leur nombre de transactions, la complexité de leurs stocks, leurs flux d’achat ou de production, leur présence multi-entités, leurs contraintes réglementaires et leur rythme de croissance.

Le point de bascule apparaît lorsque les outils qui ont accompagné les premières étapes de croissance ne permettent plus à l’entreprise de fonctionner de manière fiable sans une forte compensation humaine. Au début, il est normal qu’une organisation s’appuie sur un logiciel comptable, quelques outils métier, des fichiers Excel et une coordination très directe entre les équipes. Le dirigeant connaît les clients, les exceptions, les priorités et les personnes qui détiennent l’information. Cette agilité peut être une force.

Le problème apparaît lorsque l’organisation grandit, que les volumes augmentent, que de nouvelles activités ou entités se créent, et que le fonctionnement repose toujours sur les mêmes mécanismes informels. On commence alors à recopier la même information dans plusieurs systèmes, à consolider manuellement les données avant chaque réunion, à vérifier des stocks par téléphone ou sur Excel, à attendre une personne spécifique pour valider une commande, une marge ou un paiement, ou encore à produire les chiffres financiers plusieurs semaines après la fin du mois.

À ce stade, le système d’information n’est pas forcément défaillant au sens technique. Les outils peuvent continuer à fonctionner séparément. Mais l’entreprise, elle, commence à ne plus fonctionner comme un ensemble cohérent. Elle ne dispose plus d’une donnée unique et fiable, les équipes créent leurs propres versions de la réalité, et la direction consacre de plus en plus de temps à réconcilier les informations plutôt qu’à décider et à agir.

Le premier signal est donc une perte de confiance dans les chiffres. Lorsqu’une direction demande le niveau réel de stock, la rentabilité d’un client, les commandes à livrer, le montant des encaissements attendus ou la marge d’une activité, et reçoit plusieurs réponses selon le département interrogé, il n’existe plus de source de vérité commune. Cela crée des décisions plus lentes, plus prudentes et parfois tout simplement erronées.

Le deuxième signal est la multiplication des outils et des processus parallèles. Il ne faut pas opposer systématiquement Excel à un ERP : Excel reste un très bon outil d’analyse. En revanche, lorsqu’un tableur devient indispensable pour créer une facture, définir un prix, calculer une commission, suivre un stock ou consolider le reporting de gestion, il devient un élément critique du processus opérationnel sans offrir les contrôles, la traçabilité ou la continuité nécessaires.

Le troisième signal est la dépendance aux personnes clés. Certaines entreprises paraissent bien fonctionner jusqu’au jour où une personne part en congé, quitte l’organisation ou n’est tout simplement pas disponible. Si personne ne sait reproduire une clôture, corriger un prix, identifier la bonne version d’un fichier, comprendre un calcul de marge ou suivre une commande sans solliciter cette personne, la croissance repose davantage sur une connaissance individuelle que sur un processus maîtrisé.

Le quatrième signal est que chaque nouvelle étape de développement ajoute une charge administrative disproportionnée. Ouvrir une filiale, un entrepôt, un point de vente, un nouveau canal e-commerce ou une ligne de produits devrait créer de la capacité et de la valeur. Si cela impose systématiquement de nouveaux fichiers, de nouvelles ressaisies, des contrôles manuels et des recrutements uniquement destinés à rapprocher les informations, alors le modèle n’est plus conçu pour « scaler ».

Il existe également des signaux plus discrets, que le dirigeant ne perçoit pas toujours immédiatement. Des phrases du type « il faut vérifier avec Finance », « le stock système n’est pas toujours à jour », « ne prends pas ce rapport comme référence », « demande à telle personne », ou encore « le vrai suivi est dans mon fichier ». Ces phrases sont révélatrices. Elles montrent que les processus réels s’exécutent en dehors des outils officiels et que l’entreprise a commencé à construire une organisation parallèle, souvent invisible dans les tableaux de bord de direction.

C’est souvent là que l’intégrateur peut apporter une valeur avant même de parler de logiciel. Le rôle n’est pas de vendre un ERP dès qu’un outil existant montre ses limites. Aucun système ne résout tous les problèmes. Notre rôle est d’abord de rendre visible le coût de la fragmentation : le temps passé à réconcilier, les retards de décision, les erreurs de facturation, les pertes de marge, les surstocks ou ruptures, les difficultés de prévision de trésorerie et le risque lié à la dépendance envers certaines personnes.

Un ERP devient réellement pertinent lorsque l’entreprise a besoin de remplacer l’effort individuel par un modèle opérationnel partagé : des données de référence, des processus connectés, des validations claires, une meilleure traçabilité et une information disponible au moment où la décision doit être prise. Le bon moment pour agir n’est donc pas lorsque les outils se sont déjà effondrés, mais lorsque l’organisation constate que sa croissance dépend encore trop de la capacité de ses équipes à compenser quotidiennement les limites du système.

Quentin Mathonet

L’intégration ERP est un métier qui ne peut pas être industrialisé comme une simple production de logiciels. Chaque client a son histoire, son modèle économique, ses contraintes réglementaires, ses priorités opérationnelles, son niveau de maturité digitale et ses propres habitudes de travail. Si l’on applique la même solution à toutes les organisations, on perd précisément ce qui fait la valeur d’un intégrateur : la capacité à comprendre ce qui se passe réellement sur le terrain et à accompagner une entreprise dans des choix parfois complexes.

Pour autant, cela ne signifie pas que chaque projet doit repartir de zéro. À mes yeux, industrialiser l’intégration ERP consiste à standardiser ce qui ne devrait jamais dépendre de l’improvisation : la manière de cadrer le projet, de comprendre et prioriser les besoins, de construire une gouvernance, de documenter les décisions, de sécuriser les données, de préparer les tests, de former les utilisateurs et d’accompagner la mise en production.

Il faut également capitaliser sur l’expérience acquise d’un projet à l’autre. La plupart des intégrateurs développent progressivement une expertise forte dans certains secteurs ou certains modèles opérationnels. Cela ne veut pas dire qu’ils ne peuvent pas exceller dans d’autres industries, mais ils deviennent naturellement reconnus pour leur compréhension de problématiques précises, de flux récurrents et des contraintes propres à certains métiers.

Chez Eezee Saudi, l’un de nos domaines d’expertise les plus forts est le transport et la logistique. Nous avons construit une verticale sectorielle (que nous avons appelée « Logistics+ ») autour d’Odoo, c’est-à-dire une base qui rassemble des processus, des configurations, des fonctionnalités, des composants techniques, des scénarios de test et des bonnes pratiques déjà éprouvés dans cette industrie. Cette verticale nous permet de démarrer un projet avec une compréhension concrète des réalités du client, plutôt qu’avec une page blanche.

Logistics+ peut être déployée rapidement, mais elle doit toujours être adaptée. Chaque entreprise a ses particularités : ses flux de transport, sa tarification, ses contrats, ses contraintes de traçabilité, son modèle de facturation et son environnement applicatif. La verticale ne remplace donc jamais la phase de diagnostic. Elle fournit une base plus robuste, mais doit toujours être confrontée à la réalité de l’organisation.

Son premier bénéfice est l’accélération. Nous ne devons pas reconstruire à chaque projet des fonctionnalités qui ont déjà été éprouvées, ni redéfinir depuis le début les mêmes flux ou scénarios de test. Cela accélère le cadrage, la conception, le développement lorsque des adaptations sont nécessaires, les tests, la formation et la mise en production. Cela réduit aussi le risque : une fonctionnalité déjà utilisée et testée dans un contexte comparable est généralement plus fiable qu’une fonctionnalité conçue dans l’urgence pour un seul client.

Le deuxième bénéfice est que le client ne bénéficie pas seulement d’un outil, mais aussi de l’expérience accumulée dans son secteur. Une équipe qui connaît le transport et la logistique peut poser de meilleures questions dès le départ, identifier plus rapidement les points de vigilance, challenger les processus qui semblent être des habitudes historiques, et distinguer ce qui constitue une vraie spécificité métier de ce qui peut être standardisé. C’est cette connaissance sectorielle qui permet à un intégrateur de ne pas seulement exécuter une demande, mais de conseiller réellement le client.

Enfin, une verticale sectorielle permet d’enrichir la solution dans le temps. Lorsqu’une évolution développée pour un client répond à un besoin récurrent du secteur, qu’elle est suffisamment générique, robuste, documentée, sécurisée et maintenable, elle peut être intégrée à la verticale et proposée aux autres clients concernés. Cela crée un cercle vertueux : chaque projet alimente la connaissance collective, et les clients suivants bénéficient d’une solution plus riche et d’un retour d’expérience plus large.

C’est particulièrement important dans le cadre du développement régional d’Eezee et de l’intégration de Solution Founder en Arabie saoudite, devenue Eezee Saudi. L’enjeu n’est pas simplement d’augmenter le nombre de projets que nous pouvons livrer. Il est de combiner une expertise locale construite sur le terrain avec des méthodes, des ressources, des standards de qualité et une capacité d’exécution à l’échelle du groupe.

Cette croissance ne doit pas se traduire par une distance plus grande avec les clients. Au contraire, elle doit permettre de mobiliser la bonne expertise au bon moment : des consultants qui connaissent l’industrie, des profils finance lorsque les décisions touchent à la comptabilité, au contrôle ou à la consolidation, des experts techniques lorsque l’architecture ou les intégrations le nécessitent, et des équipes locales capables de maintenir une relation de proximité avec les décideurs et les utilisateurs.

On peut donc standardiser fortement les éléments qui assurent la qualité d’exécution : le cadre de gouvernance, les méthodes de gestion de projet, les livrables, les critères de validation, la gestion des risques, la documentation, la stratégie de tests et les mécanismes de transfert de compétences. En revanche, on ne doit jamais standardiser aveuglément la compréhension du client. Le séquencement du projet, le niveau de personnalisation, la conduite du changement, les intégrations nécessaires et la composition de l’équipe doivent toujours être adaptés à la réalité opérationnelle de l’organisation.

Pour moi, la bonne industrialisation consiste à faire circuler l’expérience, les outils et les meilleures pratiques à l’échelle régionale, sans faire disparaître le jugement métier et la proximité humaine. Une verticale n’est pas une manière d’imposer une solution préfabriquée : c’est une manière de transformer l’expérience accumulée sur le terrain en accélérateur de valeur pour le client suivant.

Quentin Mathonet

Je ne pense pas que l’intelligence artificielle fasse disparaître le métier d’intégrateur ERP. En revanche, elle va profondément faire évoluer sa valeur. Pendant longtemps, l’utilisateur a dû apprendre la logique des écrans, des menus, des filtres et des transactions du système. Demain, il pourra plus souvent interroger l’ERP en langage naturel : demander une analyse, obtenir une explication, rechercher une information, identifier une anomalie ou, dans certains cas, déclencher une action sans naviguer lui-même dans l’interface traditionnelle.

Cela simplifiera l’expérience utilisateur, mais ne rendra pas l’ERP moins important. Je dirais même que c’est l’inverse : plus l’interaction devient simple, plus l’exigence sur ce qui se trouve derrière doit être élevée. Un agent IA ne peut donner une réponse fiable que s’il s’appuie sur des données cohérentes, des définitions partagées, des processus clairement modélisés et des droits d’accès correctement définis. Si les données sont contradictoires, si le calcul de marge n’est pas stabilisé, si les rôles ne sont pas clairs ou si les processus réels se déroulent encore dans des fichiers parallèles, l’IA rendra simplement ces incohérences plus rapides et plus visibles.

Je vois donc l’IA comme un accélérateur de maturité. Elle ne corrige pas spontanément une organisation mal structurée, elle amplifie la qualité, ou au contraire les faiblesses, du système sur lequel elle est connectée. C’est pourquoi l’ERP demeure essentiel : il reste le système de référence qui organise les données, les processus, les validations, les responsabilités et la traçabilité.

La configuration restera nécessaire, mais elle ne suffira plus. La valeur de l’intégrateur se déplacera vers quatre sujets : la qualité des données, les règles métier, les droits donnés aux agents et la gouvernance des décisions automatisées.

D’abord, l’architecture des données. Il faut savoir quelles données peuvent être exposées à un agent, lesquelles doivent rester confidentielles, quelles données sont fiables et dans quel contexte elles peuvent être interprétées et utilisées. Un agent ne doit pas avoir accès indistinctement à toutes les données de l’entreprise simplement parce qu’il est connecté à l’ERP.

Ensuite, les règles métier. L’IA doit comprendre ce qu’elle peut suggérer, ce qu’elle peut préparer, ce qu’elle peut exécuter et ce qu’elle doit obligatoirement escalader à un humain. La différence est fondamentale entre demander à un agent « montre-moi les retards de paiement » et lui demander « bloque automatiquement les commandes de tous les clients en retard ». Dans le premier cas, il assiste une décision ; dans le second, il prend une décision qui peut avoir des conséquences commerciales, financières et relationnelles.

Le troisième sujet est celui des permissions. Une IA doit être traitée comme un utilisateur ou un collaborateur numérique doté d’un rôle défini, d’un périmètre limité et de droits précisément attribués. Elle doit respecter les mêmes principes de séparation des responsabilités, de périmètre multi-société et de confidentialité que les utilisateurs humains. Le principe de moindre privilège est particulièrement important : un agent doit recevoir uniquement les données et les actions nécessaires à sa mission, pas un accès global par défaut.

Enfin, il y a la gouvernance des décisions. Les entreprises devront définir explicitement quel niveau d’autonomie elles acceptent. Certaines tâches peuvent être largement automatisées : classer des demandes, préparer un brouillon de réponse, détecter des incohérences, proposer un réapprovisionnement, créer un ticket de support ou préremplir une fiche. En revanche, des décisions qui touchent à la finance, aux prix, aux paiements, aux écritures comptables, aux données clients, aux droits d’accès ou aux engagements contractuels doivent, dans la plupart des cas, conserver une validation humaine et une piste d’audit. Les recommandations de gouvernance des agents convergent sur cette séparation entre accès en lecture et capacité d’action, ainsi que sur la nécessité de journaliser les accès et les décisions.

Chez Eezee Group, nous avons déjà commencé à faire évoluer notre rôle dans cette direction. Nous avons développé Eezee Harness, un environnement sécurisé et propre à chaque client, dans lequel nos agents, mais aussi des agents configurés par le client, peuvent opérer avec un accès contrôlé aux flux, à la configuration et au code spécifique de son environnement. L’objectif est de permettre à l’IA d’apporter un contexte réellement utile, sans lui donner une liberté d’action non maîtrisée sur le système de production.

Dans cet environnement, Eezee Assist intervient sur les sujets de support : aide aux utilisateurs, réponses aux questions, analyse de problèmes, diagnostic initial, examen de flux ou de code existant et création de tickets pour les équipes Eezee. L’agent peut accélérer l’identification d’un incident et préparer les informations utiles à sa résolution, mais les recommandations et toute intervention susceptible d’avoir un impact sur le système restent revues par un consultant Eezee.

Eezee Harness inclut également Eezee Build, qui permet au client d’exprimer un besoin fonctionnel en langage naturel. L’agent peut alors préparer ou générer une évolution dans un environnement sécurisé, en tenant compte du contexte technique et fonctionnel existant. Cette évolution est ensuite déployée sur une base de test, évaluée et revue par nos spécialistes avant toute décision de mise en production.

Cette approche permet d’accélérer le support, l’analyse, la conception et les premiers travaux de développement, sans supprimer les étapes essentielles d’un projet ERP : tests, revue technique, validation fonctionnelle et décision métier. L’IA rend le cycle plus rapide et plus accessible, mais l’expertise humaine reste indispensable pour garantir la qualité, la sécurité et la pertinence de ce qui est finalement déployé.

À terme, le métier d’intégrateur sera donc moins centré sur la simple configuration d’écrans et davantage sur la conception d’un environnement de confiance. Il faudra relier correctement les données, formaliser les règles, sécuriser les accès, définir les niveaux de validation, organiser les environnements de test et de production, et être capable d’expliquer ce que l’agent a fait, sur quelle base et sous quelle autorisation.

La vraie question n’est pas tant de savoir ce que l’IA peut faire, mais quelles décisions l’entreprise accepte de lui confier, avec quelles limites, quels contrôles et quel niveau de responsabilité humaine. L’intégrateur a donc un rôle central dans cette réflexion, car il se situe précisément à l’intersection de la technologie, des processus et de la gouvernance.

Quentin Mathonet

À l’horizon 2030, je pense que l’ERP deviendra probablement moins visible pour une partie des utilisateurs, mais beaucoup plus stratégique pour l’entreprise. Ce sont deux évolutions qui peuvent sembler contradictoires, mais qui sont en réalité complémentaires.

L’ERP tel que nous le connaissons aujourd’hui a été conçu autour d’interfaces, de menus, de formulaires et de transactions. L’utilisateur devait apprendre à naviguer dans le système pour trouver une information, produire un rapport, déclencher une action ou suivre un processus. Avec les agents et les interfaces conversationnelles, cette relation va évoluer. Pour un nombre croissant d’usages, les collaborateurs s’adresseront directement à une couche d’intelligence capable de comprendre leur intention, de rechercher les informations pertinentes et de les guider vers l’action appropriée.

L’ERP deviendra donc probablement moins visible comme interface. Un utilisateur n’aura pas nécessairement besoin de savoir dans quel module se trouve une donnée, quel rapport lancer ou quelle séquence d’écrans suivre. Il pourra interagir avec son environnement de travail de manière plus naturelle, au travers d’une conversation, d’une recommandation, d’une alerte ou d’un processus automatisé.

Mais rendre l’interface moins visible ne signifie pas rendre le système moins important. Au contraire, l’ERP prendra davantage de valeur comme infrastructure centrale de l’entreprise. Il restera le lieu où les données de référence sont structurées, où les flux entre vente, achat, stock, production et finance sont reliés, où les règles de gestion sont formalisées et où les opérations conservent leur traçabilité.

La véritable évolution est donc un changement de positionnement. L’ERP ne sera plus seulement l’outil dans lequel les équipes travaillent, il deviendra de plus en plus la plateforme à partir de laquelle elles travaillent. Les interfaces conversationnelles, les outils de mobilité, les portails clients, les automatisations et les agents pourront simplifier l’accès au système, mais ils devront tous s’appuyer sur un même socle opérationnel.

La conséquence la plus importante est que l’ERP devra devenir plus ouvert, plus composable et plus simple à interroger. Sa valeur ne dépendra plus seulement de ses écrans ou de son nombre de fonctionnalités, mais de sa capacité à alimenter de façon fiable les portails, les applications mobiles, les automatisations et les agents qui entoureront l’entreprise.

C’est particulièrement pertinent dans une région comme le Moyen-Orient, où les ambitions de digitalisation sont très fortes. La Vision 2030 en Arabie saoudite, comme les stratégies de transformation numérique et d’intelligence artificielle des Émirats, créent un contexte favorable à l’adoption de nouvelles technologies. Mais la technologie seule ne crée pas un avantage durable. Elle devient réellement utile lorsqu’elle repose sur des organisations capables de structurer leur information, de faire circuler la donnée entre les départements et de prendre des décisions à partir d’un référentiel commun.

Je ne vois donc pas l’IA comme la disparition de l’ERP. Je la vois comme la fin progressive de l’ERP uniquement perçu comme une interface administrative. L’ERP deviendra moins visible en surface, mais plus central dans son rôle de colonne vertébrale opérationnelle. À mesure que les entreprises délégueront davantage d’analyses, de contrôles et de tâches aux agents, elles auront besoin d’un socle de données et de processus encore plus solide.

L’ERP de demain sera peut-être moins présent à l’écran, mais il sera davantage présent dans chaque opération, chaque décision et chaque interaction entre l’entreprise, ses équipes, ses clients et ses partenaires.