Quand un chef de projet demande des ressources supplémentaires pour un système informatique, la réponse qu’il reçoit dépend rarement de l’analyse du besoin réel. Elle dépend de la perception que la direction a de l’informatique dans l’organisation. Si l’IT est perçu comme un centre de coûts, toute demande de budget se heurte à un réflexe de réduction. Si l’IT est perçu comme un levier stratégique, les budgets se débloquent plus facilement, parfois même pour des projets qui ne le méritent pas. La matrice de McFarlan offre un cadre pour sortir de cette logique binaire et argumenter au cas par cas.
D’où vient la matrice de McFarlan?
L’outil a été formalisé en 1983 par F. Warren McFarlan, James L. McKenney et Philip Pyburn dans un article de la Harvard Business Review intitulé “The Information Archipelago”. Le constat de départ était que les organisations traitaient leur portefeuille informatique comme un bloc homogène, alors qu’il se composait en réalité d’applications aux enjeux radicalement différents.
La matrice croise deux dimensions. L’axe vertical mesure l’impact actuel de l’IT sur les opérations: si les systèmes tombent en panne, l’activité s’arrête-t-elle? L’axe horizontal mesure l’impact futur: les nouveaux projets informatiques vont-ils transformer la position concurrentielle? En 2005, Nolan et McFarlan ont reformulé ces axes en termes plus intuitifs: “IT défensif” (protéger l’existant) et “IT offensif” (conquérir de nouvelles positions).
Les quatre quadrants en pratique
Support: ne pas surinvestir
Dans ce quadrant où l’impact actuel et l’impact futur sont tous deux faibles, un logiciel de gestion des notes de frais dans une PME industrielle illustre bien la situation: utile, mais pas critique. Si le système est indisponible pendant deux jours, l’activité continue. Les projets Support méritent des processus de gouvernance allégés et constituent de bons candidats à l’externalisation, car leur valeur stratégique est limitée.
Pour le chef de projet, la leçon est claire: un projet Support ne nécessite pas de comité de pilotage mensuel avec la direction générale. Chercher à obtenir ce niveau d’attention serait contre-productif, car cela consommerait du temps de direction qui devrait être consacré à des initiatives plus critiques.
Usine: garantir la continuité
Lorsque l’impact actuel est fort mais l’impact futur reste faible, le système informatique est vital pour les opérations quotidiennes sans pour autant transformer la stratégie. Le système de paie d’un grand groupe correspond souvent à ce profil: une panne paralyse l’organisation, mais le système n’est pas un levier d’innovation.
Le chef de projet en mode Usine doit défendre les budgets de maintenance et de fiabilité: l’argument porte sur le risque opérationnel, non sur la transformation. Un SLA (Service Level Agreement, engagement contractuel sur le niveau de service garanti) solide et une surveillance continue sont les investissements prioritaires.
Virage: protéger l’avantage concurrentiel émergent
Quand l’impact actuel est faible mais l’impact futur est fort, l’entreprise n’est pas encore dépendante de l’IT au quotidien, mais elle investit dans des projets qui pourraient transformer son positionnement. Une enseigne de distribution qui déploie un système de traçabilité en temps réel pour la première fois se trouve dans cette situation.
C’est le quadrant où les erreurs de classification coûtent le plus cher. Un projet Virage traité comme un projet Support sera sous-financé, confié à des équipes non dédiées et probablement externalisé par souci d’économie. Externaliser un projet Virage revient à confier à un tiers un actif qui pourrait devenir un avantage concurrentiel décisif. Le chef de projet doit faire comprendre aux décideurs que ce type d’initiative requiert un engagement direct des directions métiers et une protection des ressources allouées.
Stratégique: mobiliser la direction générale
Quand l’impact est fort sur les deux axes, l’IT est critique aujourd’hui et le sera davantage demain. Nolan et McFarlan citaient en 2005 l’exemple de Boeing avec le programme 787, où la conception numérique était devenue le produit lui-même. Les projets de ce quadrant justifient une gouvernance au plus haut niveau, avec une implication du comité de direction voire du conseil d’administration.
Comment positionner son projet dans la grille
L’exercice de positionnement commence par deux questions concrètes posées aux parties prenantes (stakeholders, c’est-à-dire les personnes directement concernées par le projet). Que se passerait-il si ce système cessait de fonctionner demain? Et dans quelle mesure ce projet changera-t-il notre façon de travailler ou notre position sur le marché dans les deux à trois prochaines années?
Les réponses déterminent le quadrant, mais l’essentiel est que cette discussion soit collective. Un directeur financier et un directeur des opérations ne donneront pas nécessairement les mêmes réponses, et ce désaccord est productif. La grille de McFarlan fonctionne comme un révélateur d’hypothèses implicites: elle force les participants à expliciter ce qu’ils attendent de l’informatique.
De l’outil individuel à la cartographie du portefeuille
Un chef de projet utilise la matrice pour défendre le positionnement de son initiative. Un PMO (Project Management Office, le bureau de gestion de projet chargé de coordonner l’ensemble des projets) l’utilise à une autre échelle: cartographier tout le portefeuille informatique pour repérer les déséquilibres. Si la majorité des projets sont classés Stratégique sans que les ressources suivent, le portefeuille est en situation de surcharge structurelle. Si des équipes seniors sont mobilisées sur des projets Support, c’est une allocation sous-optimale.
La grille est toutefois une simplification volontaire. Elle ne couvre pas des dimensions comme la cybersécurité, la conformité réglementaire ou la dette technique, qui peuvent justifier des investissements importants indépendamment du positionnement stratégique. Le classement est aussi subjectif: deux personnes peuvent légitimement placer le même projet dans des quadrants différents, et c’est précisément pour cela que l’exercice doit être collectif. Dans certains secteurs comme la fintech ou le e-commerce, où l’IT est structurellement au coeur de l’activité, la quasi-totalité des projets se retrouve dans le quadrant Stratégique, ce qui réduit la valeur discriminatoire de l’outil. La grille stratégique ne remplace pas une analyse de rentabilité, mais elle fournit un cadre de conversation entre le chef de projet et sa hiérarchie, là où les discussions sur les priorités informatiques se réduisent trop souvent à des rapports de force budgétaires.