Aller au contenu
METHODE 7

Notre grille de diagnostic technique en douze points

Ce qu'on regarde systématiquement quand on prend en main une mission de diagnostic court. Douze points organisés en quatre familles, exploitables comme checklist.

Par Laurent

Quand on signe un diagnostic court de cinq jours, on n’a pas le temps de tout regarder. On a une grille en douze points organisés en quatre familles, qu’on déroule systématiquement pour produire un livrable comparable d’une mission à l’autre. Voici cette grille, telle qu’on l’applique en interne.

Famille 1 : la stack technique

Point 1 : cartographie des briques en place

Lister chaque système, son rôle métier, sa version, son intégration aux autres. Ça paraît trivial, mais sur la moitié des missions, le client lui-même ne dispose pas d’une cartographie à jour. On la produit en deux jours d’entretien et d’inventaire technique.

Point 2 : âge et support des composants critiques

Pour chaque brique critique, on note la version installée, la version actuelle disponible chez l’éditeur, et le statut de support (actif, en fin de vie, abandonné). Les briques en fin de vie ou abandonnées sont des risques immédiats à signaler.

Point 3 : dépendances et points de fragilité

On identifie les composants dont la défaillance bloquerait l’activité, et on évalue leur niveau de redondance. Une base de données unique sans réplication, c’est un point de fragilité. Un serveur DNS sur un seul hébergeur, c’est un point de fragilité. On les sort dans le rapport, indépendamment de l’âge.

Famille 2 : l’opérationnel

Point 4 : qualité du monitoring

Est-ce qu’on sait, en temps réel, quand un système est en panne ? Est-ce qu’on a des alertes proactives sur les indicateurs critiques (temps de réponse, taux d’erreur, saturation) ? Sur la majorité des missions, la réponse est partielle, et c’est un sujet à structurer.

Point 5 : gestion des sauvegardes

Existe-t-il un protocole de sauvegarde formalisé ? À quelle fréquence ? Et surtout : quand a-t-on testé pour la dernière fois qu’une restauration fonctionne ? Une sauvegarde non testée n’est pas une sauvegarde, c’est une supposition.

Point 6 : gestion des incidents

Quand un incident se produit, qui le traite ? Avec quelle procédure ? Combien de temps en moyenne entre le signal et la résolution ? La maturité de cette procédure est souvent inversement proportionnelle à la taille de l’équipe technique : les petites équipes improvisent, les grandes formalisent.

Famille 3 : la sécurité et la conformité

Point 7 : niveau d’accès et habilitations

Qui a accès à quoi, avec quel niveau de privilège, et qui en a la maîtrise ? On regarde particulièrement les comptes administrateurs partagés, les comptes prestataires non révoqués après fin de mission, et l’absence d’authentification forte sur les outils critiques. C’est un point qui révèle souvent des failles évidentes.

Point 8 : conformité RGPD et données personnelles

Existe-t-il un registre des traitements à jour ? Les durées de conservation sont-elles définies et appliquées ? Les transferts de données hors UE sont-ils documentés ? On ne fait pas un audit RGPD complet en cinq jours, mais on identifie les zones à risque évident pour les flagger.

Point 9 : gestion des incidents de sécurité

Est-ce qu’il y a déjà eu un incident de sécurité connu ? Comment a-t-il été géré ? Existe-t-il une procédure de réponse documentée pour le prochain ? Ce point révèle la maturité réelle plutôt que la maturité affichée.

Famille 4 : l’organisationnel

Point 10 : équipe technique en place

Combien de personnes, quel niveau d’expérience, quelle ancienneté dans le rôle, quelle stabilité. Une équipe technique senior et stable est un atout. Une équipe junior avec un fort turnover est un risque à mitiger.

Point 11 : prestataires externes et dépendances

Quels prestataires sont impliqués dans la maintenance ou l’évolution du système ? Quel niveau de criticité ? Quelle qualité de relation contractuelle (en clair, est-ce qu’on est dépendant à mort d’un prestataire qui n’a pas envie de partager le code source) ?

Point 12 : roadmap et capacité d’évolution

L’équipe a-t-elle la bande passante pour les évolutions à venir ? Existe-t-il une roadmap explicite ? Cette roadmap est-elle alignée avec les besoins métier exprimés par la direction ? Souvent on découvre un écart entre ce que la direction attend et ce que l’équipe technique pense devoir produire.

La synthèse en quatre catégories

À la fin du diagnostic, chaque point est noté sur une échelle simple : vert (rien à signaler), jaune (à améliorer dans les six mois), rouge (à traiter dans le mois). Le rapport final regroupe les points rouges en haut, suivis des jaunes.

C’est ce qui permet à la direction de prendre des décisions sur des bases concrètes, plutôt que sur une impression générale. Et c’est ce qui rend le livrable de notre diagnostic exploitable même si on ne continue pas la mission avec nous.

Pour aller plus loin

Lire comment on cadre un diagnostic technique en cinq jours pour la méthode globale, moderniser ses outils legacy en 2026 pour la suite la plus fréquente, et pourquoi on a refusé une mission à cinquante mille euros pour comprendre quand on ne signe pas. Et si vous avez un diagnostic à faire dans les mois à venir, un échange amont cale les attentes.

On en parle

Vous avez un sujet qu'on pourrait creuser ?

On a parfois besoin de creuser un sujet pour le comprendre. Si le vôtre nous parle, écrivez-nous.