Transformation Digitale : Livraison & Exécution
Les cabinets de conseil font les slides. Moi, je livre.
Transformation digitale n’est pas une stratégie à écrire. C’est une opération à exécuter. ERP migration. Cloud transition. Data & analytics strategy. API-first architecture. Supply chain digitalisée. Customer experience réinventée.
J’ai piloté la transformation IT chez Transdev : équipe IT de 200 personnes, budget de 25M€, transformation complète en 36 mois. Migration data center vers cloud. ERP moderne. Data lake pour l’analytique. Teams numériques intégrées. Livré selon le plan. Sans débordement budgétaire.
Résultats concrets :
- ERP/Systèmes critiques migrés et opérationnels : 12-18 mois
- Efficacité opérationnelle gagnée : 15-25% de productivité métier retrouvée
- Réduction coûts IT : 20% tout en doublant la capacité d’innovation
Transformation digitale ≠ Modernisation technique
Beaucoup confondent « transformation digitale » et « moderniser notre vieille infrastructure ». C’est faux.
Moderniser, c’est remplacer du legacy par du neuf. Transformation, c’est réinventer comment l’entreprise opère. Un nouvel ERP ne transforme rien si les processus métier restent les mêmes. Une migration cloud ne transforme rien si c’est juste du lift-and-shift du même code obsolète.
J’interviens sur les vraies transformations : où la technologie force le métier à penser différent. Comment on vend si nos data de client sont en temps réel au lieu de batch du soir ? Comment on gère la supply chain si elle est prédictive au lieu de réactive ? Comment on recrute si le processus est complètement dématérialisé ?
Les trois piliers d’une transformation réussie
Pilier 1 : Schéma directeur IT clair
Une stratégie IT clair : dans 3 ans, where are we going? Pas 100 pages. Une page. ERP en cloud ? Data lake pour analytics ? Zero-downtime architecture ? Modèle DevOps/Agile IT ? Ce qui change, quand, pourquoi.
Chez Transdev, le schéma était : cloud-first pour tout neuf, on migre le legacy par vagues critiques en premier, on construit une data lake pour donner à la direction visibilité temps-réel sur les opérations. Ça guidait chaque décision. Pas de débat circulaire sur la tech.
Pilier 2 : Gouvernance métier-IT forte
La transformation IT ne peut pas être piloté par l’IT seule. Faut un sponsor métier qui pèse. Les métiers doivent être dans les comités de décision. Les investissements doivent être défendus sur la base de ROI métier, pas d’arguments IT techniques.
Je mets en place une gouvernance transformation qui associe :
- Un steering committee avec le COMEX sponsor (DAF, DRH, VP ops selon le contexte).
- Des work-streams métier/IT en parallèle : ERP, data, supply chain, RH, etc.
- Des décisions rapides sur les blocages : on ne traîne pas sur des débats sans fin.
- Un reporting clair : où en sommes-nous ? Qu’est-ce qui dérape ? Quel investissement reste ?
À Elsan (healthcare), la transformation a demandé d’embarquer les directeurs d’hôpital : comment on digitalise la patient experience ? Comment on rend la pharmacie plus efficace ? C’est pas une question IT, c’est une question métier. L’IT arrive avec les réponses technologiques.
Pilier 3 : Exécution & Délivrance continue
La transformation se fait projet par projet, livraison par livraison. Pas d’un grand bang. Les enjeux majeurs :
- ERP migration : big project. Prend 12-18 mois. Doit être géré comme un portefeuille (plusieurs modules, plusieurs phases, valeur progressive). Chez Transdev, on a migré modules par modules, en parallèle sur deux zones opérationnelles, pour pouvoir apprendre et ajuster sans tout casser.
- Cloud transition : ça se fait par couches. Infrastructure d’abord (infra-as-code). Données ensuite (sans perte, sans fuite). Applications après. De la cohérence : une plateforme cloud unique (pas 5 cloud différents après 3 ans).
- Data & analytics : une data lake faut une vraie architecture. Master data management. Data quality governance. Et puis les consommateurs : BI, ML, AI. Faut que le métier voit de la valeur early (early wins : un tableau de bord qui existe pas aujourd’hui, qui aide une décision du COMEX).
- API & intégration : une vraie stratégie d’intégration : comment les systèmes parlent ensemble ? API-first ? ou ESB classique ? Une fois défini, ça donne un cadre clair aux devs.
Je mets en place une gouvernance de délivrance : chaque mois, on regarde : qu’est-ce qu’on a livré au métier ? Est-ce que c’est selon le plan ? Sinon, pourquoi, et on ajuste.
Les scénarios typiques de transformation
Scénario 1 : Migration ERP complète
Vous êtes sur un SAP / Oracle vieux de 15 ans. C’est un dinosaure. Coût de maintenance dingue. Aucune agilité. Vous avez décidé : 3 ans, on migre vers un ERP cloud moderne (SAP Cloud, Oracle Cloud, ou même une solution alternative).
Comment je pilote ça :
- Semaine 1-2 : audit du vieux ERP. Qu’est-ce qui marche, qu’est-ce qui est crap, qu’est-ce qui ne sera jamais utilisé dans le neuf.
- Semaine 3-4 : design du nouvel ERP. Pas une réplication du vieux. Une réinvention. On apprend du vieux, mais on réinvente les processus (parfois, la migration c’est l’occasion de tuer 30% des processus legacy qui n’avaient plus de sens).
- Mois 2-4 : mise en place du nouvel ERP en bac à sable. Configuration, design des données, préparation de la migration de données.
- Mois 4-12 : déploiement par modules. Pas tout à la fois. Un module par trimestre. D’abord les modules critiques (finance, supply), après les modules moins critiques (projects, HR).
- Mois 12-18 : stabilisation, ajustements, montée en efficacité. Les utilisateurs apprennent. Les processus se stabilisent.
À Beaumanoir, on était sur un ancien Infor. Migration vers SAP Cloud en 18 mois. Budget respecté. Plus de 500 utilisateurs formés. Nouvelle supply chain en temps réel (au lieu de batch du soir). Amélioration de 18% de la rotation inventory.
Scénario 2 : Cloud transition pour l’infrastructure
Vous avez vos propres data centers. C’est du legacy. Cloud change le modèle économique : capex en opex, scalabilité au lieu de pré-provisioning, automatisation.
Plan de 24 mois :
- Cartographie complète de la charge actuelle : quels serveurs, quels services, quelle criticité.
- Stratégie de migration : ce qui est « cloud-ready » (applications stateless, pas de composants bizarres), on peut migrate vite. Ce qui est legacy custom, faut un refactoring d’abord ou une migration plus lente.
- Déploiement par vagues : applications non-critiques d’abord (quick wins). Critique ensuite (avec test intensif). Hyperritique à la fin (avec rollback plans ultra détaillés).
- Arrêt progressif des data centers : une fois qu’une app s’en va au cloud, la place se libère, les coûts baissent, la charge du data center descend.
Chez Transdev, on était sur 2 data centers propriétaires + 2 cloud publics. Consolidation en 1 cloud public majeur en 24 mois. Économies : 3M€ au Year 1 vs ancienne baseline. Scalabilité gagnée : on peut doubler la capacité en 2 semaines au lieu de 6 mois.
Scénario 3 : Data & Analytics transformation
Vous avez des données partout (Excel, databases legacy, data marts obsolètes, BI sans gouvernance). Vous avez décidé : data lake moderne, analytics unifiée, AI/ML ready.
Plan de 18-24 mois :
- Master data design : qu’est-ce que sont les vraies entités métier (client, produit, commande, etc.). Comment on les réconcilie dans toutes les sources.
- Data lake architecture : on choisit une plateforme (Databricks, Snowflake, AWS data lake, etc.), on définit un schema. On met les données dedans de façon structurée.
- Data quality governance : qui owns chaque donnée. Comment on la valide. Comment on l’met à jour.
- Analytics & BI : une fois qu’on a les données propres, on peut faire de la BI qui marche. Tableaux de bord, reports, dashboards temps-réel.
- AI/ML use-cases : churn prediction ? Demand forecasting ? Price optimization ? Une fois qu’on a une data lake solide, on peut explorer.
À Elsan (healthcare), on a construit une data lake pour avoir visibilité temps-réel sur les opérations : patients à la mauvaise place, capacité d’opération, occupation des lits. Les directeurs d’hôpital voir chiffre clés à chaque matin. Ça a amélioré l’efficacité opérationnelle de 12%.
Scénario 4 : Transformation métier pilotée par la tech (QSR, e-commerce, etc.)
Vous êtes dans un secteur où la digitale transforme vraiment le business. QSR (quick service restaurant) : comment tu commands, comment tu payes, comment tu reçois. E-commerce : comment tu découvres, comment tu achètes, comment tu payes. RH : comment tu recrutes, comment tu onboards.
C’est pas une transformation IT. C’est une transformation métier enablee par la tech. L’IT arrive avec les briques techniques, mais le métier doit conduire. À Buffalo Grill (QSR), la transformation : système de commande mobile + AI pour prédire la demande + automatisation de la cuisine. L’IT a mis en place la plateforme. C’est le métier qui a redessiné l’expérience.
Les pièges de la transformation IT
Piège #1 : Stratégie floue, exécution frustrée
Vous lancez une transformation sans vraie stratégie. Au bout de 6 mois, vous avez fait 10 petits trucs, aucun cohérent. L’équipe IT ne sait pas où on va. Le COMEX pense qu’on traîne.
Solution : un schéma directeur SI clair AVANT de lancer. Une page. Pas 100. Où on va en 3 ans. Comment on y arrive. Quels sont les 3 gros chantiers. Qui paie, combien, quand.
Piège #2 : Métier absent de la gouvernance
L’IT pilote la transformation toute seule. Le métier s’en fout au départ, et puis à la fin, quand on livre, il dit « c’est pas ce qu’on voulait ». C’est un classique du SAP.
Solution : mettre le métier dans le steering. Pas cosmétique. Vraiment. Des VP métier, des directeurs opérationnels. Eux qui valident les specs, qui arbitrent sur les choix, qui disent oui/non aux investissements.
Piège #3 : Perfection technique au lieu de pragmatisme métier
L’IT veut l’architecture parfaite. Cloud-native. Microservices. Zero-downtime. Mais ça prend 3 ans de plus et coûte 50% plus cher. Pragmatisme : qu’est-ce que le métier veut vraiment ? ERP qui marche ? Data lake qui aide les décisions ? OK, on vise 80% de perfection technique, 100% de pragmatisme métier.
Piège #4 : Oublier la formation & change management
Vous avez livré un nouvel ERP super. Sauf que les utilisateurs ne savent pas s’en servir, on perd 2M€ de productivité en Year 1. Une transformation IT, c’est 20% technologie, 80% change. Les gens doivent apprendre. Faut un budget formation robuste.
Comment on démarre ?
Vous avez une transformation IT en tête : migration ERP, cloud transition, data lake. Je propose une intervention courte : diagnostic rapide 4 semaines (où êtes-vous vraiment, qu’est-ce qui fonctionne, qu’est-ce qui est bloqué), schéma directeur proposé, plan de pilotage.
Ensuite, deux options : (a) je deviens DSI transition, je pilote la transformation 24-36 mois. (b) Je reste en coaching/sparring avec votre DSI permanent, on structure la gouvernance ensemble.
À Transdev, c’était l’option (a) : j’ai piloté la transformation IT en tant que DSI. 25M€ de budget, 200 personnes d’équipe, 36 mois. Livré. Chez Elsan, c’était option (b) : j’ai coacé le DSI en place, on a structuré la gouvernance ensemble, le DSI a piloté la data lake.