Comment collaborer efficacement : créer une véritable alliance entre consultants fonctionnels et techniques

(Deuxième partie sur cinq de la série « Le code humain des ERP »)

Soyons honnêtes. Si vous avez déjà travaillé dans le domaine de la mise en œuvre de logiciels d'entreprise, vous avez probablement constaté qu'il existe souvent des tensions entre les consultants fonctionnels et les consultants techniques.

Entre eux se trouve un gouffre d'incompréhension, d'e-mails passifs-agressifs et de retards dans les échéanciers des projets.

L'incident d'intégration simple

J'ai vu des projets s'enliser pendant des semaines simplement parce que deux professionnels parlaient des langues complètement différentes.

Imaginez une réunion d'alignement typique. Le consultant fonctionnel, tout juste rentré d'un atelier avec le client, se penche en avant et déclare : « Le client doit synchroniser son logiciel de production avec son ERP. C'est très simple. Il nous suffit de mettre en place une intégration basique avec son MES actuel pour transférer les données. »

Le problème, c'est que le consultant fonctionnel présente la solution comme « facile » principalement parce qu'il n'est pas chargé de coder. Il fournit très peu de détails et prend l'exécution technique à la légère, sous-estimant complètement les importantes implications techniques.

Pour le consultant, une intégration n'est qu'un pont conceptuel. Pour le développeur, cette même « intégration simple » se révèle être un véritable cauchemar : structures de données complexes, erreurs de délai d'attente, jetons de sécurité et validations de données manquantes.

Lorsque le développeur souligne inévitablement ces complexités, des frictions inutiles surgissent. Le consultant fonctionnel estime que le développeur complexifie inutilement un besoin métier. Le développeur, quant à lui, a le sentiment que le consultant fonctionnel dévalorise son travail et fait des promesses irréalisables au client.

En réalité, le métier de consultant fonctionnel présente des difficultés que le développeur ne peut appréhender, et inversement. Le développeur n'a pas à gérer les exigences irrationnelles d'un client paniqué, et le consultant fonctionnel n'a pas à se confronter à la logique implacable de l'architecture système. Aucune de ces professions n'est moins importante ou plus simple que l'autre. Elles font simplement face à des défis spécifiques que l'autre partie rencontre rarement.

Le véritable ennemi dans cette pièce, c'est l'ego et le manque de compréhension mutuelle.

Bienvenue dans la deuxième partie de « Le code humain des ERP ». Aujourd’hui, nous allons décloisonner les services entre les concepteurs des processus métier et ceux qui les mettent en œuvre.

Nous parlons de la manière de forger une alliance à toute épreuve entre les équipes fonctionnelles et techniques.

Deux mondes, deux langues

Pour résoudre ce conflit, il faut d'abord en comprendre la cause profonde. Les consultants fonctionnels et techniques évoluent dans deux réalités totalement différentes.

Le consultant fonctionnel évolue dans le monde complexe et imprévisible des entreprises. Il arpente les chaînes de production, constate les efforts physiques des opérateurs, et comprend les angoisses du directeur financier ainsi que les méthodes parfois chaotiques et illogiques qui caractérisent l'exécution des tâches quotidiennes. Son objectif : assurer le bon fonctionnement de l'entreprise.

Le consultant technique évolue dans un monde régi par une logique binaire et absolue. Une table de base de données se moque bien de savoir si le responsable d'entrepôt passe une journée stressante. Une architecture système exige des règles strictes, des définitions précises et une absence totale d'ambiguïté. Son objectif : garantir la stabilité, la sécurité et la performance du système.

Lorsque ces deux mondes se rencontrent sans interprète, c'est la catastrophe. On se retrouve avec une intégration système techniquement irréprochable, mais totalement inutilisable pour les opérateurs en atelier, car elle ne tient pas compte des délais physiques liés au déplacement des palettes par un chariot élévateur.

Le mythe du consultant technique

On croit souvent, à tort, que pour combler cet écart, un consultant fonctionnel doit apprendre à coder. C'est totalement faux. Un excellent consultant fonctionnel ERP n'a pas besoin de savoir programmer ou écrire des requêtes SQL complexes.

Cependant, ils doivent absolument savoir comment fonctionne.

Vous n'avez pas besoin de savoir comment rédiger la charge utile de l'API. En revanche, vous devez comprendre que lorsqu'un système envoie un message, il attend une réponse spécifique, et vous devez concevoir un processus métier pour gérer l'absence de cette réponse. Vous devez comprendre la différence entre une table de données de référence et une table transactionnelle. Vous devez maîtriser les principes fondamentaux de l'architecture système.

Votre véritable rôle de consultant fonctionnel est d'être un véritable interprète des besoins humains. Vous êtes le lien, pas un programmeur. Vous devez transformer les besoins complexes et souvent émotionnels de l'entreprise en un cadre logique et clair, exploitable par un développeur.

Protéger les tranchées

Le pire type de consultant fonctionnel est l'exécutant aveugle. Ce consultant ne se soucie guère des besoins réels de l'entreprise. Il exécute les ordres comme un simple soldat, écoutant une demande de personnalisation illogique ou totalement irréalisable du client, la notant mot pour mot et la transmettant directement à l'équipe technique sans se demander si elle est pertinente.

L'architecture moderne de CloudSuite empêche de littéralement casser la base de données, mais les utilisateurs demanderont tout de même des modifications qui contreviennent totalement à la logique standard du système. Lorsque le développeur fait inévitablement remarquer que la demande est techniquement absurde, ce type de consultant hausse simplement les épaules et dit : « Ne m'en voulez pas. C'est ce que veut le client. »

Ce comportement détruit la confiance au fil du temps. Il pénalise l'équipe technique.

Un véritable consultant agit comme un rempart. Il est de votre responsabilité de déterminer si une demande est totalement irréalisable avant de la transmettre au service informatique. Vous devez appliquer la méthode des « Cinq Pourquoi » abordée dans la première partie et identifier le véritable besoin métier.

De plus, si le développeur a des difficultés à respecter une exigence, il ne suffit pas de se référer au cahier des charges et d'exiger des résultats. Il faut collaborer avec lui et mener une enquête conjointe pour déterminer si la limitation technique est objective. Si tel est le cas, il est indispensable de jouer un rôle de médiateur et de retourner voir le client afin de trouver un compromis.

Les clients adorent répéter : « En informatique, tout est possible. » Il est essentiel de protéger votre équipe technique de cette mentalité, car la réalité est tout autre. Nous ne réécrivons pas les processus fondamentaux de A à Z. Nous étendons les fonctionnalités standard.

Lorsque les développeurs comprendront que vous êtes là pour les guider, les protéger des promesses irréalistes et éliminer les idées reçues, ils vous respecteront. Ils cesseront de s'opposer à vos demandes et commenceront à collaborer à vos solutions.

Prendre la chaleur

Les consultants fonctionnels se plaignent souvent d'une situation bien précise. Lorsqu'un script personnalisé dysfonctionne ou qu'un système plante, le consultant technique reste confortablement installé derrière son écran. Pendant ce temps, le consultant fonctionnel doit se retrouver en réunion, affronter un client mécontent et expliquer pourquoi la personnalisation récemment déployée ne fonctionne pas comme prévu. Il est particulièrement injuste d'endosser la responsabilité d'une erreur technique dont on n'est pas à l'origine.

Que cela vous plaise ou non, votre rôle est précisément d'assurer la liaison entre l'équipe technique et le client. Vous êtes le lien. Se plaindre d'être en contact avec le client, c'est comme se plaindre de recevoir des coups avec un bouclier.

Le secret d'un projet réussi réside dans la défense mutuelle. Une alliance solide implique un soutien réciproque. Le consultant fonctionnel encaisse les chocs, gère les critiques et apaise la frustration du client, ce qui permet de gagner un temps précieux. Cette dynamique n'est possible que si le développeur apporte son soutien.

Dans un véritable partenariat, dès que le consultant entre dans cette salle de réunion tendue, le développeur est déjà informé et travaille en coulisses pour corriger le problème. Vous protégez le développeur de la panique du client, et le développeur préserve votre crédibilité en corrigeant rapidement le bug.

Le guide de l'Alliance

Comment transformer un service informatique hostile en votre meilleur allié ? Voici trois règles pratiques à appliquer lors de votre prochain projet pour bâtir un véritable partenariat.

1. Rédigez des spécifications binaires, pas des romans

Les développeurs détestent l'ambiguïté plus que tout au monde. N'écrivez jamais une spécification fonctionnelle qui dit : « Le système doit automatiquement mettre à jour le statut et en informer l'utilisateur. » C'est un roman, pas une spécification. Utilisez plutôt une logique binaire. Spécifiez précisément quel déclencheur initie l'événement. Définissez précisément quel champ de la table doit passer du statut A au statut B.

Précisez le contenu exact de la notification et son destinataire précis. Supprimez les adjectifs et remplacez-les par des termes précis. Si votre cahier des charges laisse place à l'interprétation, il est inadéquat. Même les moindres détails doivent être formalisés et partagés. Une brève réunion de concertation pour examiner ces détails au préalable peut grandement faciliter l'adoption d'un langage commun.

2. Toujours expliquer le « pourquoi » dans l'analyse

Lors de la rédaction de vos spécifications fonctionnelles, vous devez clairement expliquer les motivations métier qui sous-tendent la demande. Ne considérez pas le développeur comme un simple exécutant de code. À l'instar des consultants fonctionnels, les développeurs ont besoin du contexte complet de l'exigence. Ils doivent comprendre ce sur quoi ils travaillent, mais surtout, pourquoiils le font. Ne vous contentez pas de leur fournir des instructions techniques.

Expliquez le problème rencontré par l'entreprise. Par exemple : « Les employés de l'entrepôt saisissent actuellement ce numéro manuellement 500 fois par jour, ce qui entraîne des retards de livraison. Nous devons automatiser ce champ pour leur faire gagner deux heures par poste. » Lorsqu'un développeur comprend le contexte et l'impact humain de son code, il passe du rôle de simple exécutant à celui de partenaire actif, capable de proposer une solution technique bien plus performante que celle initialement envisagée.

3. Intégrez-les au voyage

Dans la plupart des projets, c'est le consultant fonctionnel qui se déplace chez le client et participe aux réunions importantes. Cette dynamique isole souvent le développeur dans les bureaux. Si vous souhaitez réellement travailler en équipe, vous devez adopter les bonnes pratiques. Il ne suffit pas de solliciter vos collègues techniques uniquement pour leur confier une tâche de codage précise, sans leur fournir le contexte global.

Vous devez leur donner le sentiment d'être partie intégrante du projet. Profitez-en pour échanger régulièrement avec eux et les tenir informés des dernières évolutions chez le client, des changements de cap du projet et de l'ambiance générale. Ce suivi constant garantit leur implication. Lorsque les développeurs comprennent la vision d'ensemble et se sentent pleinement intégrés, ils ne sont plus de simples exécutants, mais de véritables partenaires. Un projet où consultant fonctionnel et développeur travaillent en étroite collaboration donnera sans aucun doute d'excellents résultats, tant pour le projet que pour leur travail quotidien.

L'Alliance dans les tranchées

Développer une extension personnalisée ou intégrer un logiciel externe à un ERP ne se résume jamais à écrire des lignes de code. C'est un exercice de communication humaine.

Même la plus grande architecture technique au monde s'effondrera si les personnes qui définissent le processus et celles qui développent la logique refusent de se comprendre. En mettant de côté notre ego, en apprenant à communiquer clairement et en respectant le temps de chacun, nous pouvons mettre fin à cette guerre sans fin et commencer à créer des logiciels qui font réellement la différence.

La réussite d'une mise en production repose en grande partie sur l'alliance indéfectible entre un consultant fonctionnel et un consultant technique. Aucun des deux ne peut réussir seul.

Prochain sujet : Comment cultiver la compétence la plus sous-estimée du secteur du conseil. Nous explorerons le pouvoir de la curiosité par rapport à la mémoire encyclopédique.

Écrit par Andrea Guaccio 

7 mai 2026