En bref : pour ceux qui sont pressés
Le DSI ou RSI en PME est souvent coincé entre des équipes métier qui veulent tout, tout de suite, et des contraintes techniques qui imposent des arbitrages. Son rôle dans un projet ERP ou CRM n'est pas seulement technique : c'est celui d'un traducteur, d'un arbitre, et d'un garant de la cohérence d'ensemble. Bien positionné, il est le facteur clé de réussite du projet.
La fracture métier/technique : d'où vient-elle vraiment ?
Dans la plupart des projets ERP qui déraillent, on retrouve le même schéma. Les équipes métier ont exprimé des besoins, parfois flous, parfois très précis. Le prestataire technique a livré quelque chose, parfois conforme, parfois à côté. Et entre les deux, personne n'a vraiment joué le rôle de pont.
Ce n'est pas une question de mauvaise volonté. C'est une question de langage et de priorités. Un responsable commercial pense en termes de processus de vente, de relances, de pipeline. Un développeur pense en termes de tables de données, d'API, de temps de traitement. Sans quelqu'un pour faire la traduction, les deux camps travaillent en parallèle, et se retrouvent avec une surprise au moment de la mise en production.
C'est précisément le terrain du DSI ou du RSI en PME.
Le rôle pivot du DSI/RSI dans un projet ERP ou CRM
Le Directeur des Systèmes d'Information (ou Responsable SI dans les structures plus petites) n'est pas là pour choisir la couleur des boutons. Son rôle dans un projet ERP est stratégique à trois niveaux.
Côté métier : comprendre les processus réels de chaque service, pas ceux qui sont théoriquement décrits dans les procédures. Ce sont souvent deux choses différentes. Un bon DSI passe du temps sur le terrain avant de rédiger quoi que ce soit.
Côté technique : évaluer la faisabilité de ce qui est demandé, estimer les impacts sur l'infrastructure existante, identifier les points de friction entre le nouvel outil et les systèmes déjà en place.
Côté projet : s'assurer que les décisions prises sont documentées, que les arbitrages sont tranchés par les bonnes personnes, et que les engagements pris par le prestataire sont réalistes (voir notre article sur le rôle de l'AMOE externe).
Traduire les besoins métier en cahier des charges technique
C'est la phase la plus délicate et celle où se jouent souvent les dérapages futurs.
Les ateliers de recueil des besoins
Un bon atelier de recueil ne ressemble pas à une réunion PowerPoint. C'est une session de travail où l'on suit un processus étape par étape, avec les personnes qui font réellement le travail, pas uniquement leurs managers.
Quelques principes qui font la différence :
Travailler sur des cas concrets ("montrez-moi comment vous traitez une commande client aujourd'hui") plutôt que sur des généralités
Distinguer ce qui est un besoin réel de ce qui est une habitude de travail héritée d'un ancien outil
Documenter les exceptions autant que les cas standard : ce sont souvent elles qui posent problème en production
Ne pas promettre de solution pendant l'atelier : noter, comprendre, puis arbitrer en dehors
La priorisation MoSCoW
Tout le monde veut tout. C'est humain. La méthode MoSCoW permet de sortir de cette impasse de façon non conflictuelle.
Must have : sans ça, le projet ne peut pas démarrer
Should have : important, mais une solution de contournement temporaire est acceptable
Could have : utile, mais reportable sans impact significatif
Won't have (pour l'instant) : explicitement exclu du périmètre de la première version
Cette priorisation doit être faite avec les équipes métier, pas pour elles. Et elle doit être validée par la direction parce que certains arbitrages ont des implications organisationnelles qui dépassent le DSI.
La documentation fonctionnelle
Le cahier des charges fonctionnel n'a pas besoin d'être un document de 200 pages. Il doit être suffisamment précis pour qu'un prestataire puisse chiffrer sans ambiguïté, et suffisamment lisible pour qu'un directeur métier puisse le valider sans être informaticien.
Une bonne structure par processus (achat, vente, stock, comptabilité…) avec pour chaque processus : le flux actuel, le flux cible, les règles de gestion, les volumes, et les contraintes. C'est tout.
Arbitrer entre ce qui est souhaitable et ce qui est faisable
C'est la partie la moins confortable du rôle et la plus utile.
Dire non, ou "pas maintenant", à une demande métier légitime demande du courage et de la pédagogie. Le DSI/RSI doit être capable d'expliquer pourquoi une fonctionnalité demandée aurait un impact disproportionné sur le planning ou le budget, sans que l'interlocuteur métier ait l'impression d'être ignoré.
Quelques leviers concrets pour ces arbitrages :
Chiffrer l'impact : "cette fonctionnalité représente trois semaines de développement supplémentaires et 8 000 € de plus. Voulez-vous qu'on l'intègre au déploiement initial ou qu'on la planifie en version 2 ?"
Proposer des alternatives : avant de dire qu'une demande est impossible, vérifier si un paramétrage astucieux ou un module standard peut couvrir 80% du besoin sans développement spécifique.
Documenter les choix : chaque arbitrage est noté, avec la date, les participants, et la décision prise. Indispensable pour éviter les révisions intempestives trois mois plus tard.
Collaborer avec une AMOA et une AMOE externe
Le DSI/RSI n'est pas seul. Dans la plupart des projets PME, il travaille avec une AMOA qui pilote le projet côté maîtrise d'ouvrage (voir notre article sur le rôle du chef de projet AMOA), et une AMOE qui réalise techniquement la solution.
Son rôle dans cette configuration triangulaire :
Valider la cohérence technique des choix proposés par l'AMOE
Alerter l'AMOA quand une demande métier est techniquement risquée ou sous-estimée
Être le point de contact unique côté client pour les questions d'architecture et d'infrastructure
Assurer la continuité après le projet : c'est lui qui reprend l'outil en main une fois le prestataire parti
Ce dernier point est souvent négligé. Le DSI/RSI doit anticiper la phase post-déploiement dès le début du projet : documentation technique, formation de l'équipe interne, accès aux environnements, procédures de sauvegarde et de maintenance.
Maintenir l'alignement tout au long du projet
Le cadrage initial ne suffit pas. Les besoins évoluent, les priorités changent, et la réalité du terrain réserve toujours des surprises. Quelques pratiques simples pour maintenir l'alignement :
Un comité de pilotage mensuel avec les décideurs métier et la direction, pas pour rentrer dans les détails techniques, mais pour valider les orientations et débloquer les décisions qui traînent
Un point hebdomadaire avec le prestataire AMOE : pour suivre l'avancement réel, identifier les blocages, et ajuster le planning si nécessaire
Une démo régulière aux utilisateurs clés : montrer l'outil en construction, même imparfait, vaut mieux que de tout révéler le jour de la recette (voir notre article sur la validation avant déploiement)
Un registre des évolutions : toute demande de modification par rapport au cahier des charges initial est tracée, chiffrée, et validée avant d'être réalisée
FAQ : questions fréquentes
Un RSI sans expérience ERP peut-il piloter ce type de projet ?
Oui, à condition d'être bien entouré. L'expertise ERP peut venir de l'AMOA externe ou du prestataire. Ce que le RSI doit apporter, en revanche, est irremplaçable : la connaissance de l'entreprise, de ses données, de son infrastructure, et de ses acteurs. C'est cette connaissance contextuelle qui fait la différence.
Comment gérer un directeur métier qui contourne le DSI pour parler directement au prestataire ?
C'est un risque réel qui génère des incohérences et des surcoûts. La solution n'est pas d'interdire le contact, mais de cadrer les échanges : tout besoin exprimé directement au prestataire doit passer par le DSI/RSI avant d'être pris en compte. Ce point doit être acté dans le contrat avec le prestataire.
Faut-il impliquer le DSI/RSI dans le choix de l'outil avant le déploiement ?
Absolument et le plus tôt possible. Un choix d'outil fait sans le DSI peut aboutir à un logiciel incompatible avec l'infrastructure existante, ou dont les coûts d'intégration n'ont pas été anticipés. Son regard technique en phase de sélection évite des mauvaises surprises coûteuses.
Comment le DSI/RSI doit-il gérer la sécurité des données pendant le projet ?
Le projet ERP implique des accès à des données sensibles (clients, finances, RH) par des prestataires externes. Le DSI doit prévoir : des accès nominatifs et limités dans le temps, des environnements de test distincts de la production, un accord de confidentialité, et une revue des accès à la fin du projet.
DSI/RSI et e-facturation : quel est l'impact sur le projet ERP ?
L'obligation de facturation électronique en France implique des choix techniques structurants : format des factures (FactureX, Peppol…), connexion à une plateforme de dématérialisation partenaire (PDP), archivage légal. Ces sujets doivent être intégrés dès le cahier des charges, pas traités en fin de projet comme un module optionnel.
Comprendre les besoins et les traduire techniquement, c'est bien. Mais comment la direction financière pilote-t-elle sa performance avec ces nouveaux outils ? C'est l'objet de notre prochain article dédié aux DAF et RAF.