Situation illustrative : un lundi matin, le DSI doit répondre à trois alertes contradictoires. La facture du cloud public dérive, un serveur hébergé en interne approche de sa limite de capacité et le RSSI refuse de déplacer une application sensible tant que la restauration n’a pas été testée. Le directeur financier demande pourtant une décision avant le prochain budget. Le sujet n’est donc pas de choisir une infrastructure « moderne », mais de déterminer où placer chaque charge sans fragiliser l’exploitation, enfermer l’entreprise chez un fournisseur ni payer deux fois la même capacité.
Le vrai problème : des contraintes qui ne se déplacent pas
Une migration change le lieu d’exécution, pas la nature de l’application. Un ERP ancien reste peu élastique dans un cloud public. Une plateforme privée ne devient pas résiliente parce qu’elle est dédiée. Un serveur interne ne garantit pas la souveraineté si son administration, ses sauvegardes ou ses licences dépendent entièrement de tiers.
L’arbitrage commence donc par les contraintes réelles : criticité du processus, sensibilité des données, latence acceptable, dépendance au réseau, variabilité de la demande, exigences de restauration, compétences disponibles et durée de vie prévisible. Le cloud public apporte élasticité, services managés et rapidité de mise à disposition. Le cloud privé renforce le contrôle et peut stabiliser certains coûts, au prix d’une exploitation exigeante. L’hébergement interne ou managé garde du sens pour des charges stables, des équipements physiques ou des opérations qui doivent continuer malgré une liaison dégradée.
Refuser le classement par étiquette
La mauvaise question est : « Quel modèle devons-nous privilégier ? » La bonne est : « Quel risque acceptons-nous pour cette charge, et qui saura le maîtriser ? » Une application commerciale soumise à des pics peut justifier le cloud public. Une base très intégrée à des machines de production peut rester proche du site. Un service sensible mais standardisable peut rejoindre une plateforme privée correctement opérée.
Le DSI doit aussi distinguer hébergement et services. Une application peut être exploitée par un prestataire sur une infrastructure dédiée, tandis que l’architecture, les identités et les clés de décision restent gouvernées en interne. L’hybride n’est pas un entre-deux commode : il précise ce que l’entreprise sait faire, ce qu’elle délègue et ce qu’elle doit pouvoir reprendre.
Construire un dossier de décision par charge
Première étape : constituer une fiche courte pour chaque application, avec son propriétaire métier, ses dépendances, ses flux, ses fenêtres d’arrêt et son mode dégradé. Deuxième étape : comparer les scénarios sur un horizon cohérent, en intégrant migration, réseau, licences, sauvegardes, supervision, support, compétences et sortie du fournisseur. Le prix affiché d’une machine virtuelle ne constitue jamais un coût complet.
Troisième étape : tester les hypothèses critiques. Une restauration doit être exécutée, pas seulement décrite. La performance doit être vérifiée depuis les sites utilisateurs. La portabilité doit être démontrée sur les données, les configurations et les procédures d’exploitation. Enfin, le comité d’arbitrage consigne la décision, les conditions qui la rendent valable et la date de réexamen. Une décision réversible vaut mieux qu’une préférence technologique devenue doctrine.
Mesurer ce qui révèle la maîtrise
Les indicateurs utiles relient finance, exploitation et risque. Le coût complet par application doit inclure les équipes, les transferts de données, les outils communs et les engagements inutilisés. Le suivi de capacité compare ressources réservées, consommation réelle et marge nécessaire. La résilience se mesure par les restaurations réussies, le temps réellement observé pour reprendre le service et la fréquence des tests.
Il faut également suivre les incidents liés au réseau, aux identités, aux changements fournisseurs et aux erreurs d’administration. Un indicateur de concentration rend visibles les applications dépendantes d’un même opérateur, d’une même région ou d’une compétence rare. La couverture documentaire et le nombre de personnes capables d’exploiter chaque plateforme signalent, eux, la dépendance humaine.
Anticiper les erreurs qui coûtent après la décision
La première erreur consiste à migrer avant de cartographier les dépendances : l’application démarre, mais les échanges avec l’ERP, l’annuaire ou les équipements locaux deviennent lents ou fragiles. La deuxième est de surdimensionner un cloud privé au nom de la prudence, puis de découvrir que la capacité immobilisée manque de souplesse. La troisième est d’adopter des services managés sans préparer l’export des données, la reconstruction des configurations et la continuité des compétences.
Autre piège : confondre localisation et sécurité. Le contrôle dépend aussi des droits d’administration, de la journalisation, du chiffrement, de la séparation des responsabilités et des exercices de crise. Enfin, conserver une infrastructure interne par habitude peut être aussi risqué que migrer par effet de mode : matériel vieillissant, procédures tacites et sauvegardes jamais restaurées produisent une maîtrise fictive.
Trancher avec des règles explicites
L’arbitrage final peut tenir en trois décisions. Placer dans le cloud public les charges variables ou celles qui tirent un bénéfice réel de services managés, à condition de borner les coûts et la dépendance. Réserver le cloud privé aux actifs justifiant contrôle, standardisation et capacité dédiée, avec une équipe capable de l’opérer. Maintenir en interne ou en hébergement managé les charges stables, contraintes par le terrain ou difficilement déplaçables, sans différer leur sécurisation.
Le livre « Révolution Numérique ! » de Guy de Lussigny fournit ici un cadre pertinent : relier les choix technologiques aux coûts, aux risques et aux dépendances. La décision du dirigeant IT n’est pas un vote pour une plateforme. C’est une règle d’allocation vérifiable, assortie d’un responsable, d’indicateurs, d’un scénario de sortie et d’une échéance de révision. Le bon modèle est celui que l’entreprise peut expliquer, exploiter, restaurer et, si nécessaire, quitter.
Pour approfondir
Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon
Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon
#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique
