Ce qu’une évaluation d’infrastructure de deux semaines devrait livrer

Ce que deux semaines permettent, et ce qu’elles ne permettent pas

Deux semaines, c’est environ dix jours ouvrés. C’est assez pour comprendre en profondeur une partie convenue d’un parc : une plateforme, un ensemble d’applications, un candidat à la migration ou une chaîne de livraison. Ce n’est pas assez pour évaluer tout ce que vous exploitez, et un évaluateur qui le promet promet un rapport superficiel.

Le document le plus important s’écrit donc avant le début des travaux : le périmètre. Il doit nommer les systèmes et environnements concernés, les questions auxquelles l’évaluation doit répondre, ce qui est exclu et qui est disponible de votre côté. Un partage courant consacre environ la moitié du temps à la découverte et aux entretiens, et l’autre moitié à l’analyse et à la rédaction. Une évaluation n’est pas non plus une mise en œuvre. Si des changements commencent pendant l’évaluation, les constats cessent de décrire le parc que vous avez réellement.

Ce que vous devriez préparer

La plupart des évaluations perdent leurs premiers jours à attendre des accès. Organisez un accès en lecture seule aux systèmes concernés avant le premier jour, et rassemblez ce qui existe déjà : schémas d’architecture, même périmés, exports d’inventaire ou de CMDB, tableaux de bord de supervision, les six à douze derniers mois d’incidents et de changements, et les dates de renouvellement et de fin de support des licences et contrats concernés.

Réservez du temps avec les personnes qui savent comment les choses fonctionnent vraiment : les ingénieurs qui exploitent la plateforme, ceux qui y déploient et le responsable qui la finance. Quelques heures d’entretien avec chacun suffisent généralement. Les documents décrivent le système prévu ; les personnes décrivent le système réel.

Le déroulement habituel des deux semaines

Une évaluation bien menée a un rythme visible. Les deux ou trois premiers jours sont consacrés au lancement, aux accès et aux entretiens, pour confirmer que le périmètre et les questions tiennent toujours une fois que l’évaluateur a vu le parc. Le milieu de la première semaine et le début de la seconde sont consacrés à la découverte concrète : lire les configurations, tracer les dépendances, vérifier ce que font réellement la supervision et les sauvegardes, et parcourir la chaîne de livraison avec ceux qui l’utilisent.

Les derniers jours sont consacrés à l’analyse et à la rédaction. Demandez un court point d’étape à la fin de chaque semaine. Le premier permet de corriger une hypothèse erronée tant qu’il est encore temps ; le second présente en avance les principaux constats pour que la restitution ne surprenne pas les personnes les plus concernées. Si vous n’avez aucune nouvelle pendant dix jours puis recevez un rapport terminé, l’évaluateur a travaillé autour de vous, pas avec vous.

Une image de l’existant

Le premier livrable est une description exacte de l’état actuel. Pour l’infrastructure, c’est la topologie : systèmes, dépendances, flux de données, versions et statut de support, y compris ce qui a déjà dépassé sa fin de support. Pour la livraison, c’est la chaîne : comment un changement arrive en production, qui l’approuve, ce qui est testé en chemin et comment une mauvaise version est annulée.

Une bonne évaluation distingue ce qui a été vérifié de ce qui a été déclaré. « La sauvegarde tourne chaque nuit » n’a pas le même sens quand quelqu’un l’affirme et quand l’évaluateur a vu une restauration réussie. Vous devez pouvoir faire la différence.

Des constats classés par risque, preuves à l’appui

Chaque constat doit comporter sa preuve, son impact, la probabilité que le problème survienne et, approximativement, l’effort de correction. Les constats doivent ensuite être classés. Une liste de 200 points de poids égal est un transfert de travail, pas un résultat. Vous voulez savoir quelles cinq choses comptent ce trimestre.

Séparez les risques urgents des améliorations. Les versions non supportées, les points uniques de défaillance et les sauvegardes jamais restaurées passent en tête. Des conventions de nommage plus propres, non. Une grille de lecture cohérente aide : examinez chaque système sous l’angle de la fiabilité, de la sécurité, du coût, de l’exploitabilité et des performances, et appuyez-vous pour le détail sur des références reconnues et indépendantes des fournisseurs, comme le NIST Cybersecurity Framework pour la sécurité, organisé autour de six fonctions : gouverner, identifier, protéger, détecter, répondre et rétablir. Utilisez un référentiel comme liste de contrôle de couverture, pas comme le livrable lui-même.

Une architecture cible défendable

L’architecture cible doit être un document écrit, pas seulement un schéma. Elle doit dire à quoi le parc devrait ressembler, pourquoi, quelles alternatives ont été envisagées et pourquoi elles ont été écartées, et quelles contraintes ont guidé le choix : budget, compétences, contrats, réglementation ou calendrier.

Elle doit aussi dire ce qui reste en l’état. Une cible qui remplace tout est rarement crédible, et connaître les parties saines est utile aussi.

Une séquence avec retour arrière

Une cible sans trajectoire est un souhait. L’évaluation doit proposer un ordre de mouvements fondé sur les dépendances et le risque, avec un plan de retour arrière pour chaque mouvement et des points de décision clairs où vous pouvez vous arrêter, changer de cap ou continuer.

Elle doit aussi chiffrer le coût de l’inaction : renouvellements de licences qui vous engageront pour une nouvelle période, versions qui sortent du support à des dates connues, et risques qui grandissent tant que rien ne change. C’est souvent ce qui justifie d’agir, ou d’attendre délibérément.

Une restitution pour ceux qui décident

Le dernier livrable est une restitution pour la direction : les décisions à prendre, les options pour chacune, leurs risques et l’effort approximatif. On doit pouvoir agir sans l’évaluateur dans la salle. Les documents détaillés restent avec vos ingénieurs.

La mise en œuvre doit être chiffrée séparément et ne jamais conditionner l’évaluation. Les constats ne sont fiables que s’ils seraient identiques, que vous confiiez ou non la correction à l’évaluateur.

Après la restitution

Une évaluation ne vaut son prix que si quelque chose se passe ensuite. Transformez les constats classés en un backlog que votre équipe s’approprie, avec un responsable et une date cible pour les points prioritaires. Certains risques, comme une version non supportée en production ou une sauvegarde jamais restaurée, doivent être corrigés en quelques semaines, quelle que soit la suite.

Servez-vous ensuite de l’architecture cible et de la séquence pour décider comment réaliser le travail : avec votre équipe, avec l’évaluateur, avec un autre prestataire ou avec un mélange des trois. Comme les documents vous appartiennent, ce choix reste ouvert. Revoyez les constats au bout d’un trimestre : une évaluation encore exacte six mois plus tard, et dont les risques prioritaires ont été traités, a rempli son rôle.

Les signaux d’alerte

Méfiez-vous des constats sans preuve, des listes génériques de bonnes pratiques qui pourraient décrire n’importe quelle entreprise, et des recommandations que seul le produit de l’évaluateur peut satisfaire. Méfiez-vous d’une liste non classée, d’une architecture cible sans trajectoire de migration, d’une trajectoire sans retour arrière, et d’un périmètre qui a grandi discrètement jusqu’à « tout » sans que le temps augmente.

Enfin, vérifiez à qui appartiennent les livrables. Vous devez recevoir chaque document dans un format modifiable et être libre de le partager avec qui vous voulez, y compris un autre prestataire.

Ce que couvre notre Sprint d’évaluation

Notre Sprint d’évaluation est construit autour de ces livrables : une revue de deux semaines de l’environnement convenu, un audit de la topologie et de la chaîne de livraison, une architecture cible écrite, une séquence de migration avec des plans de retour arrière et une restitution pour la direction. Le tarif est forfaitaire, le périmètre est convenu par écrit avant le paiement et toute mise en œuvre est chiffrée séparément.