Préparer un diagnostic de votre système d’information

1. Partir des activités qui doivent fonctionner

Listez les opérations dont l’interruption gênerait directement votre entreprise : prendre une commande, accéder au stock, préparer la paie ou consulter un dossier. Pour chacune, identifiez le responsable métier, les personnes concernées et les périodes sensibles.

Décrivez l’impact d’un arrêt avec des faits : saisies reportées, équipes mobilisées, livraisons décalées. Précisez les moyens de travail temporaires réellement disponibles. Cette description est plus utile qu’une appréciation générale comme « tout est critique ».

2. Relier les usages aux outils et aux sites

Pour chaque activité, indiquez l’application utilisée, les sites qui y accèdent et les interlocuteurs qui la maintiennent. Ajoutez les dépendances connues : connexion Internet, messagerie, impression, échanges avec un autre logiciel ou alimentation électrique.

• Liste des sites et personne à contacter sur chacun.
• Applications principales, versions connues et responsables métier.
• Équipements et connexions nécessaires aux usages prioritaires.
• Prestataires concernés et limites connues de leurs interventions.

Il n’est pas nécessaire de dessiner une architecture détaillée à ce stade. L’enjeu est d’éviter qu’un outil ou un site essentiel soit oublié dans le périmètre.

3. Décrire des incidents observables

Choisissez quelques situations représentatives et consignez les faits. Pour chaque incident, indiquez la date, l’opération tentée, les utilisateurs touchés, le message observé et la solution temporaire utilisée. Ajoutez un numéro de ticket si vous en disposez.

Exemple de fiche de préparation : « Lors de la consultation du stock depuis l’agence, le chargement devient lent en fin de journée. Les autres usages restent à vérifier. Référent : responsable d’agence. Résultat attendu : consulter le stock dans les conditions de travail habituelles. » Cet exemple décrit un symptôme sans lui attribuer prématurément une cause.

4. Rassembler les documents utiles

• Inventaire disponible des équipements et des applications.
• Schémas existants et procédures d’exploitation, même partiels.
• Périmètres de maintenance et interlocuteurs des prestataires.
• Historique des incidents et changements récents.
• Comptes rendus de sauvegarde et de tests de restauration disponibles.
• Projets prévus, échéances métier et décisions en attente.

Préparez une liste des documents plutôt que d’envoyer immédiatement des exports complets. Ne placez pas de mots de passe ni de données métier sensibles dans un formulaire de contact. Les modalités de consultation des informations nécessaires sont à organiser avec les intervenants désignés.

5. Fixer le périmètre et les décisions attendues

Écrivez ce que le diagnostic doit permettre d’arbitrer : conserver ou remplacer un équipement, organiser l’assistance, préparer une évolution applicative ou prioriser les investissements. Identifiez les personnes qui valideront les constats et celles qui décideront de la suite.

Un responsable métier doit pouvoir préciser le résultat attendu. Le référent IT apporte les éléments techniques disponibles. La direction indique les contraintes de budget, de calendrier et de mobilisation des équipes.

6. Vérifier la préparation avant l’échange

• L’objectif du diagnostic tient dans une phrase claire.
• Les activités, applications et sites prioritaires sont identifiés.
• Les incidents sont décrits avec des faits et des interlocuteurs.
• Les informations manquantes apparaissent explicitement.
• Les livrables et les modalités de restitution restent à convenir au cadrage.

Retrouvez les réponses aux questions de périmètre dans la FAQ et notre démarche de conseil et DSI externalisé.