Stratégie et pilotage¶

Un directeur technique qui ne comprend pas la stratégie d'entreprise fait des choix techniques dans le vide — et les defend sans arguments face aux decideurs.

Pourquoi la stratégie est une compétence technique¶

La plupart des DSI et directeurs techniques ont été formes à la technique. Les concepts de stratégie d'entreprise leur semblent relever du marketing ou du consulting. C'est une erreur qui coûte cher.

Les choix technologiques majeurs — build vs buy, cloud vs on-premise, monolithe vs microservices, plateforme proprietary vs open source — sont des choix strategiques autant que techniques. Ils engagent l'organisation sur des années, consomment des ressources significatives, et créent des dépendances irreversibles. Les prendre sans cadre strategique, c'est les prendre au feeling.

Comprendre la stratégie d'entreprise permet au DSI de :

• Traduire les objectifs business en choix techniques argumentes
• Anticiper les besoins IT avant qu'ils deviennent urgents
• Arbitrer entre les demandes concurrentes avec une grille de priorité cohérente
• Justifier les investissements techniques aupres d'un COMEX non-technique
• Identifier les risques strategiques avant qu'ils deviennent des crises opérationnelles

Analyse externe : comprendre l'environnement¶

Les 5 forces de Porter¶

Michael Porter a formalisé en 1979 un cadre d'analyse de l'attractivite d'un secteur. Les cinq forces déterminent la pression concurrentielle et donc la marge de manœuvre strategique de l'entreprise.

Application DSI : une entreprise sous forte pression concurrentielle avec des entrants digitaux doit prioriser le time-to-market. Une bureaucratie IT lente avec des cycles de livraison trimestriels est un risque strategique, pas juste un problème de productivité.

Analyse PESTEL¶

Le PESTEL (Politique, Économique, Social, Technologique, Environnemental, Legal) identifie les facteurs macro-environnementaux qui affectent l'organisation. Pour un DSI, les dimensions les plus pertinentes :

Technologique : émergence de l'IA generative, évolution des plateformes cloud, maturité du edge computing, évolution des standards de sécurité. La veille technologique n'est pas optionnelle — rater une évolution majeure peut créer un ecart compétitif structurel.

Legal : RGPD, NIS2, DORA (pour les institutions financieres), IA Act europeen. Les contraintes reglementaires créent des exigences IT non-negociables. Les ignorer jusqu'au dernier moment produit des projets de conformité en urgence, coûteux et mal exécutés.

Économique : inflation, coût du capital, disponibilité des talents tech. En periode de taux élevés, les investissements IT sont soumis à une exigence de ROI plus stricte. Le passage de "on construit parce que c'est bien" a "on justifie chaque euro" est brutal pour les équipes habituees à l'abondance budgetaire post-COVID.

Veille technologique structurée¶

La veille n'est pas lire des newsletters. C'est un processus délibéré avec des sources identifiées, des fréquences définies, et un circuit de partage.

Sources primaires : publications academiques (ACM, IEEE), rapports Gartner/Forrester, state of DevOps (DORA), Stack Overflow survey, CNCF landscape.

Sources secondaires : blogs d'ingénieurs de référence (Netflix Tech, Cloudflare Blog, Martin Fowler), conferences (KubeCon, re:Invent, FOSDEM), GitHub trending.

Circuit de partage : les insights de veille doivent atterrir dans des décisions concrètes. Un format efficace : note mensuelle de 2-3 pages avec les signaux significatifs, leur interpretation strategique, et les actions recommandees. Partagee avec le COMEX et les leads techniques.

Analyse interne : évaluer les capacités¶

SWOT appliqué à la DSI¶

L'analyse SWOT (Forces/Faiblesses/Opportunités/Menaces) est trop souvent faite en surface. Appliquee serieusement a une DSI, elle produit un diagnostic exploitable.

Chaîne de valeur¶

La chaîne de valeur de Porter distingue les activités primaires (qui créent directement de la valeur pour le client) des activités de support (qui permettent aux activités primaires de fonctionner).

Pour un DSI, la question est : ou la DSI est-elle dans la chaîne de valeur de l'entreprise ?

• Activité primaire : dans une entreprise dont le produit est digital (e-commerce, fintech, SaaS), la DSI est au cœur de la chaîne de valeur. L'IT n'est pas un support — c'est le produit.
• Activité de support : dans une entreprise manufacturiere ou de services non-digitaux, l'IT supporte les processus métier. Elle crée de la valeur indirectement.

Cette position détermine le niveau d'investissement justifiable, les interlocuteurs pertinents, et la manière de mesurer la contribution IT.

Ressources et compétences¶

Le cadre RBV (Resource-Based View) de Barney analyse les ressources de l'organisation selon quatre critères : Valeur, Rarete, Inimitabilite, Non-substituabilite (VRIN). Seules les ressources VRIN constituent des avantages compétitifs durables.

Application IT : une équipe data science capable de construire des modèles ML spécifiques au métier est une ressource VRIN si elle crée un avantage que les concurrents ne peuvent pas répliquer facilement. En revanche, une infrastructure cloud standard n'est pas une ressource VRIN — les concurrents peuvent l'acheter chez le même fournisseur.

Cette analyse guide les décisions build vs buy : construire ce qui est differentiant, acheter ce qui est commodite.

Du diagnostic à l'objectif : Balanced Scorecard¶

Robert Kaplan et David Norton ont propose en 1992 le Balanced Scorecard (BSC) comme outil de pilotage strategique multi-dimensionnel. Le BSC traduit la stratégie en objectifs mesurables sur quatre perspectives.

Les quatre perspectives¶

Financiere : comment créé-t-on de la valeur pour les actionnaires ? Revenue, marge, ROI, cash-flow.

Client : comment sommes-nous perçus par nos clients ? Satisfaction, fidelisation, part de marche, NPS.

Processus internes : dans quels processus devons-nous exceller ? Délais, qualité, innovation, conformité.

Apprentissage et croissance : comment développé-t-on nos capacités ? Compétences, culture, systèmes d'information, leadership.

Cascade vers la DSI¶

La puissance du BSC est dans sa capacité a cascader — les objectifs strategiques de l'entreprise se traduisent en objectifs opérationnels par niveau.

graph TD
    A[Strategie entreprise\nCroissance 20% CA en 2 ans] --> B[Perspective financiere\nReducer TCO IT de 15%]
    A --> C[Perspective client\nTime-to-market < 2 semaines]
    A --> D[Perspective processus\nTaux de livraison en continu > 90%]
    A --> E[Perspective apprentissage\n80% des devs certifies cloud]

    B --> B1[DSI : renegocier contrats\nlicences, migrer vers cloud]
    C --> C1[DSI : pipeline CI/CD\nautomatise, feature flags]
    D --> D1[DSI : DORA metrics,\npost-mortems systematiques]
    E --> E1[DSI : plan de formation\nannuel, budget certifications]

Tableau de bord DSI¶

Le tableau de bord du DSI doit lier les métriques techniques aux objectifs business. Un tableau de bord purement technique (CPU usage, uptime) ne parle pas aux decideurs. Un tableau de bord purement business (satisfaction client) n'est pas actionnable par les équipes techniques.

KPI techniques (DORA metrics) :

KPI business :

OKR : Objectives and Key Results¶

Les OKR, popularises par Intel puis Google, sont un système de fixation d'objectifs qui aligne l'organisation sur des priorités claires, avec un rythme trimestriel.

Structure d'un OKR¶

Objective : qualitatif, inspirant, memorisable. Il dit "ou allons-nous ?" sans mesure. Exemple : "Devenir la référence en matiere de fiabilité pour nos clients."

Key Results : quantitatifs, mesurables, ambitieux. Ils disent "comment saurons-nous que nous sommes arrives ?" Chaque objective a 2 a 5 key results maximum.

Exemple DSI :

Objective : Rendre nos deployments invisibles pour nos utilisateurs

  KR1 : Taux de deployments sans downtime > 99% au T3
  KR2 : Change failure rate < 3% en production
  KR3 : Time to restore < 30 minutes pour 95% des incidents P1
  KR4 : Zero rollback d'urgence non planifie en Q3

Alignement et rythme¶

Rythme trimestriel : les OKR sont définis en début de trimestre, suivis bi-mensuellement, evalues en fin de trimestre. Un cycle annuel est trop lent pour corriger la direction ; un cycle mensuel est trop court pour observer des résultats.

Scoring : les OKR sont notes de 0 a 1 en fin de trimestre. Un score de 0.7 est considéré comme un succès — des OKR atteignables a 100% sont trop peu ambitieux. Des OKR systematiquement a 0.2 sont trop ambitieux ou les KR sont mal choisis.

Alignement vertical : les OKR de l'entreprise descendent vers les OKR des BU, puis vers les OKR des équipes. L'alignement n'est pas mecanique (les équipes ne copient pas les OKR du dessus) mais cohérent (les OKR d'équipe contribuent aux OKR de la BU).

Alignement horizontal : les OKR d'équipes interdependantes doivent être vérifiés pour éviter les conflits. Une équipe platform avec un OKR "réduire les coûts cloud de 20%" peut contraindre les équipes produit qui ont besoin de nouvelles ressources.

De la stratégie à la roadmap technique¶

Traduction des objectifs business¶

Le DSI est le traducteur entre deux langages : le langage business (croissance, marche, expérience client, compliance) et le langage technique (architecture, dette, performance, scalabilité).

Processus de traduction :

1. Partir des objectifs strategiques de l'entreprise (3-5 ans)
2. Identifier les capacités IT nécessaires pour les atteindre
3. Évaluer l'ecart entre les capacités actuelles et les capacités cibles
4. Prioriser les initiatives selon l'impact business et le coût
5. Sequencer en roadmap avec des jalons mesurables

Exemple concret :

• Objectif business : doubler le volume de transactions en 18 mois
• Capacité IT requise : architecture scalable a x10 de la charge actuelle, zero-downtime deployments, observabilité complète
• Ecart identifié : architecture monolithique avec base de données single point of failure, deployments manuels, monitoring rudimentaire
• Initiatives : migration vers une architecture evenementielle (Q1-Q2), automatisation CI/CD (Q1), mise en place d'une stack observabilité (Q2), plan de scalabilité base de données (Q2-Q3)

Arbitrage build vs buy¶

L'arbitrage entre développer en interne (build), acheter un produit (buy), ou s'abonner a un service (SaaS) est une décision strategique, pas juste technique.

Règle empirique : construire ce qui est differentiant et spécifique au métier, acheter ce qui est standard. Un système de recommendation de contenu pour une plateforme media : build ou buy selon le niveau de personnalisation. Un système de gestion des conges : buy systematiquement.

Cadre de reporting : méthode, usage, fréquence, public¶

Le reporting est le lien entre la stratégie et l'exécution. Un reporting mal calibre — trop technique, trop fréquents, trop aggreage — ne sert personne.

Principes d'un bon reporting¶

Exception-based : ne rapporter que ce qui s'écarté de la norme. Un KPI dans les clous n'a pas besoin d'un paragraphe. Un ecart significatif merite une analyse et une action.

Actionnable : chaque indicateur doit être lie a une décision possible. Si personne ne peut agir sur un chiffre, le supprimer.

Calibre au public : un COMEX a besoin d'une page avec trois indicateurs clés. Un lead technique a besoin du détail des métriques DORA par équipe. Produire un rapport unique pour tout le monde produit un document inutile pour tout le monde.

Stable dans le temps : changer les indicateurs trop souvent interdit la lecture des tendances. Stabiliser un tableau de bord pendant au moins deux ans avant de l'évoluer.

Construire le plan strategique IT¶

Le plan strategique IT (PSIT) ou schéma directeur est le document de référence qui formalise la vision IT a 3-5 ans, les initiatives prioritaires, et les ressources nécessaires.

Structure type :

1. Contexte et diagnostic : situation actuelle, analyse SWOT, contraintes majeures
2. Vision et ambition : ou veut-on aller, quel est le scenario cible a 3 ans
3. Axes strategiques : 3 a 5 axes prioritaires (ex: modernisation applicative, renforcement sécurité, transformation data, évolution des compétences)
4. Feuille de route : initiatives par axe, sequencement, dépendances
5. Budget previsionnel : enveloppes par axe, CapEx vs OpEx, courbe d'investissement
6. Gouvernance : instances de pilotage, indicateurs de suivi, révisions prévues

Pieges courants :

• Trop technique pour le COMEX (qui ne vote pas le budget) et pas assez pour les équipes (qui doivent l'exécuter)
• Trop optimiste sur les capacités d'exécution
• Ignorance des contraintes de personnel et de compétences
• Absence de scenarios alternatifs (que se passe-t-il si le budget est coupe de 20% ?)
• Révisions trop rares — un plan a 5 ans non révisé devient obsolète en 18 mois