Prioriser les investissements SI sans céder aux effets de mode

15 novembre 2026

Quand toutes les demandes paraissent stratégiques

Situation illustrative : au même comité d’investissement, le DSI doit défendre le remplacement d’un stockage vieillissant, le RSSI réclame une meilleure maîtrise des comptes à privilèges, la direction commerciale veut un assistant d’intelligence artificielle et les opérations signalent des lenteurs sur l’ERP. L’enveloppe ne permet pourtant pas de tout financer. Le vrai problème n’est donc pas de désigner la technologie la plus prometteuse, mais de décider quel risque, quelle contrainte ou quelle occasion l’entreprise doit traiter en premier. Si le débat commence par les solutions, le fournisseur le plus convaincant ou le métier le plus pressant impose son agenda. Il doit commencer par les conséquences opérationnelles d’un refus ou d’un report.

Remplacer le catalogue de projets par une carte des dépendances

Une liste de projets mélange généralement des réalités incomparables : conformité, dette technique, continuité, productivité, croissance, confort utilisateur ou expérimentation. Pour arbitrer, le dirigeant IT doit d’abord relier chaque demande à un processus critique : vendre, produire, livrer, facturer, payer, protéger les accès, restaurer les données ou respecter un engagement contractuel. Il identifie ensuite les actifs et dépendances qui soutiennent ce processus : application, infrastructure, fournisseur, compétence rare, interface ou donnée de référence.

Une modernisation réseau n’est plus un achat d’équipements ; elle devient la condition mesurable du fonctionnement de sites, de la supervision et de la sécurité. Inversement, une plateforme séduisante peut perdre sa priorité si elle ne résout aucun goulot documenté. L’objectif n’est pas de produire une architecture parfaite, mais de rendre visible ce qui casserait, qui serait touché et quelles solutions de repli existent.

Noter les décisions, pas la popularité des technologies

Une grille utile doit rester courte et commune à tous les dossiers. Cinq questions suffisent souvent. Quel processus est concerné ? Quelle perte ou exposition est évitée ? Quelle capacité nouvelle sera réellement utilisée ? Quelles dépendances supplémentaires seront créées ? Que se passe-t-il si l’investissement est décalé de six ou douze mois ? Chaque réponse doit s’appuyer sur un fait observable : incidents, indisponibilités, délais, tâches manuelles, échéances, obsolescence annoncée ou concentration fournisseur.

La note finale ne doit pas devenir une vérité mathématique. Elle sert à révéler les désaccords. Le RSSI peut juger un risque intolérable quand la direction financière estime son impact absorbable ; le DSI doit alors formuler l’arbitrage explicitement. Un classement sérieux distingue aussi l’urgence de l’importance. Une faille exploitable sur un composant exposé appelle une action rapide. Une refonte d’urbanisation peut être plus structurante, sans exiger le même calendrier.

Construire des scénarios plutôt qu’un budget binaire

Présenter chaque initiative comme « à financer » ou « à abandonner » enferme le comité. Le DSI gagne à proposer trois trajectoires. La première sécurise le minimum vital : corriger l’exposition majeure, maintenir le support et préserver la continuité. La deuxième traite durablement la cause et améliore l’exploitation. La troisième ajoute une ambition de transformation ou d’innovation. Chaque scénario précise coût complet, ressources internes, délai, risques résiduels, réversibilité et engagements fournisseurs.

Un sujet émergent peut recevoir une expérimentation bornée, avec données non sensibles, utilisateurs désignés, budget plafonné et critères d’arrêt. Il ne concurrence alors ni la sauvegarde, ni la résilience de l’ERP, ni la correction d’une faiblesse d’accès. L’innovation reste possible, mais elle doit gagner le droit de passer à l’échelle par des résultats observables, pas par la pression médiatique.

Mesurer ce qui change réellement dans l’exploitation

Les indicateurs doivent suivre l’effet attendu, pas l’activité du projet. Pour la continuité : temps de restauration éprouvé, couverture des tests et dépendances sans solution de repli. Pour la cybersécurité : comptes privilégiés maîtrisés, vulnérabilités critiques hors délai, capacité à détecter et contenir un incident. Pour un ERP : transactions bloquées, ressaisies, interfaces défaillantes, durée des clôtures ou dépendance à des traitements manuels. Pour un service utilisateur : délai de résolution, récurrence des incidents et satisfaction après résolution.

Il faut également suivre le coût complet : licences, intégration, exploitation, compétences, sortie du contrat et consommation variable. Un investissement moins cher à l’achat peut devenir prioritaire à tort s’il déplace la charge vers les équipes ou crée une dépendance coûteuse. Le comité doit revoir les bénéfices après mise en service et arrêter ce qui ne produit pas l’effet promis.

Éviter les trois pièges qui faussent l’arbitrage

Premier piège : confondre nouveauté et avantage. Une technologie récente n’a de valeur que reliée à une décision, un processus et un responsable d’usage. Deuxième piège : laisser les obligations techniques invisibles absorber le budget sans traduction métier. Le renouvellement d’un composant doit être expliqué par l’exposition évitée, la continuité préservée ou la capacité rendue possible. Troisième piège : sous-estimer le renoncement. Ajouter une plateforme mobilise l’architecture, la sécurité, les achats, le support et les métiers ; ce temps n’est alors plus disponible ailleurs.

Les ouvrages Révolution Numérique ! et DSI EN CRISE peuvent ici servir de repères de gouvernance : le premier pour relier les choix technologiques à la performance, aux risques et aux dépendances ; le second lorsque l’accumulation d’urgences a déjà dégradé la capacité d’arbitrage. Ils ne remplacent ni les preuves internes ni la décision du comité.

Faire assumer l’arbitrage final au bon niveau

Le DSI ou le RSSI ne doit pas demander au comité de valider une liste opaque. Il doit annoncer la décision attendue : financer, différer, réduire le périmètre, expérimenter ou accepter un risque. Sa recommandation tient sur une logique claire : protéger d’abord les processus vitaux et les expositions non tolérables, préserver ensuite les capacités indispensables, puis financer les améliorations dont l’usage et les résultats peuvent être vérifiés.

Le compte rendu doit nommer ce qui est accepté : risque résiduel, dette prolongée, dépendance fournisseur ou bénéfice reporté. Cette trace évite que le prochain incident transforme une décision collective en faute supposée de la DSI. Prioriser ne consiste pas à prédire la technologie gagnante. C’est choisir lucidement ce que l’entreprise protège, ce qu’elle développe et ce qu’elle accepte de ne pas faire maintenant.