Rédiger une procédure, un compte rendu d'intervention ou un rapport

Une procédure informatique décrit, étape par étape, comment réaliser une opération technique de façon sûre et reproductible ; un compte rendu d'intervention raconte ce qui a été fait sur un incident ou une demande, pourquoi, et avec quel résultat. Ce chapitre donne la structure de ces documents, puis celle des rapports de test et d'incident et de l'argumentaire technique qui justifie un choix, avec un exemple complet de chacun tiré de Sorbier Logistique.

Procédure, mode opératoire, fiche réflexe : quelle différence ?

Les mots varient d'une entreprise à l'autre ; ce qui compte, c'est de savoir quel besoin chaque document couvre.

Dans les démarches qualité, la procédure décrit l'organisation et renvoie à des modes opératoires pour les gestes techniques. Dans la plupart des services informatiques, on appelle « procédure » le document pas à pas complet, et c'est ce sens que garde ce cours. Une procédure longue gagne à s'appuyer sur des modes opératoires réutilisables : « créer l'enregistrement DNS (voir MO-AD-004) ».

L'anatomie d'une procédure

Une procédure se lit dans un ordre précis : on vérifie qu'on a le droit et les moyens de la suivre, on se protège, on agit, on contrôle, et on sait revenir en arrière.

Trois rubriques font la différence entre une procédure d'étudiant et une procédure professionnelle :

• Le résultat attendu de chaque étape : il transforme une liste de commandes en une suite de contrôles. Si le résultat n'est pas celui attendu, on s'arrête avant d'aggraver la situation.
• Le retour arrière : comment remettre l'état initial si l'opération échoue à mi-chemin. Sans lui, personne n'ose suivre la procédure en production.
• Les actions d'après : une VM créée mais absente du plan d'adressage, de l'inventaire, de la supervision et des sauvegardes est une future panne invisible.

Exemple complet : déployer un serveur dans le VLAN 21

Sorbier Logistique installe un wiki interne. Moussa Diallo écrit la procédure qui crée sa machine virtuelle à partir du modèle Debian 13 du cours Virtualisation. Elle sera réutilisée pour chaque nouvelle application : seuls le nom, le numéro et l'adresse changent.

PROC-INFRA-012 : Déployer un serveur Debian 13 dans le VLAN 21 à partir du modèle 9000

Version 1.1 du 08/11/2026. Auteur : Moussa Diallo. Relecteur : Chloé Lambert. Statut : validé.

Objet. Créer une machine virtuelle Debian 13 prête à recevoir une application interne, dans le VLAN 21 APPLIS (192.168.21.0/24, passerelle 192.168.21.254). L'installation de l'application elle-même fait l'objet d'une autre procédure. Exemple utilisé : srv-wiki, VM 190, adresse 192.168.21.190.

Public et droits. Technicien du service informatique, connecté en root à l'hôte pve1 par le bastion ; compte d'administration du domaine pour l'étape DNS.

Prérequis.

• L'adresse et le nom sont réservés dans le plan d'adressage (onglet VLAN 21).
• Le numéro de VM est libre : qm list ne contient pas de VM 190.
• Le modèle 9000 (modele-debian13) existe et le stockage truenas-nfs est disponible.
• Le fichier /root/cles-equipe.pub de pve1 contient les clés publiques SSH à jour des techniciens, celles qu'ils utilisent sur le bastion (une clé par ligne).

Impact et durée. Aucune coupure de service. Environ 15 minutes, dont 2 minutes d'attente au premier démarrage.

Point de retour. Aucun : l'opération ne modifie rien d'existant. Le retour arrière supprime ce qui a été créé.

Étapes. Sur pve1, en root :

1. Crée un clone complet du modèle :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm clone 9000 190 --name srv-wiki --full --storage truenas-nfs
   

   Résultat attendu : la commande se termine sans erreur et qm list affiche la VM 190 nommée srv-wiki, à l'état stopped.
2. Fixe les ressources :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm set 190 --cores 2 --memory 4096
   

3. Branche la carte réseau dans le VLAN 21. Attention : le modèle est étiqueté dans le VLAN 20 ; sans cette étape, la VM aurait une adresse du VLAN 21 dans le VLAN 20 et ne joindrait pas sa passerelle.
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm set 190 --net0 virtio,bridge=vmbr0,tag=21,firewall=1
   

4. Donne l'adresse fixe et les clés SSH de l'équipe par cloud-init. Le modèle ne déclare que la clé de pve1, or l'administration passe par le bastion :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm set 190 --ipconfig0 ip=192.168.21.190/24,gw=192.168.21.254 --sshkeys /root/cles-equipe.pub
   

5. Agrandis le disque à 30 Go :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm disk resize 190 scsi0 30G
   

6. Contrôle la configuration avant de démarrer :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm config 190 | grep -E 'net0|ipconfig0|sshkeys'
   

   Résultat attendu : la ligne net0 contient tag=21, la ligne ipconfig0 contient ip=192.168.21.190/24,gw=192.168.21.254, et une ligne sshkeys est présente (les clés y sont encodées : chaque espace devient %20). Sinon, reprends l'étape 3 ou 4.
7. Démarre la VM et attends deux minutes (cloud-init installe les mises à jour) :
   bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   qm start 190
   

8. Sur srv-ad, dans une console PowerShell d'administration, crée l'enregistrement DNS :
   powershellCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

   Add-DnsServerResourceRecordA -ZoneName "ad.sorbier.example" -Name "srv-wiki" -IPv4Address "192.168.21.190"
   Resolve-DnsName srv-wiki.ad.sorbier.example
   

   Résultat attendu : Resolve-DnsName renvoie l'adresse 192.168.21.190.

Vérification finale. Depuis le bastion, avec ta clé :

bashCopier le code de la section Exemple complet : déployer un serveur dans le VLAN 21

ssh sorbier-admin@192.168.21.190 hostname
ssh sorbier-admin@192.168.21.190 getent hosts srv-ad.ad.sorbier.example

Résultat attendu : la première commande affiche srv-wiki ; la seconde, 192.168.10.177 suivi de srv-ad.ad.sorbier.example. Le serveur est joignable par le chemin d'administration prévu, il porte le bon nom et il interroge bien le DNS du domaine. L'enregistrement srv-wiki lui-même a été contrôlé à l'étape 8 ; ne le teste pas sur le serveur : cloud-init a inscrit son propre nom dans son fichier /etc/hosts, avec l'adresse 127.0.1.1, et getent lit ce fichier avant d'interroger le DNS.

Retour arrière. Sur pve1 : qm stop 190, puis qm destroy 190 --purge 1. Sur srv-ad : Remove-DnsServerResourceRecord -ZoneName "ad.sorbier.example" -RRType "A" -Name "srv-wiki" -Force. Libère l'adresse dans le plan d'adressage.

Après l'opération.

• Plan d'adressage : passe la ligne 192.168.21.190 de réservée à attribuée.
• GLPI : crée la fiche de la machine virtuelle (nom, hôte pve1, VLAN 21, ticket d'origine).
• Supervision : ajoute l'hôte dans Zabbix avec le modèle Linux.
• Sauvegarde : ajoute la VM 190 à la tâche de sauvegarde nocturne de Proxmox.
• Pare-feu : les flux vers l'application (HTTPS depuis le VLAN 10) font l'objet d'une demande de changement séparée.
• Ticket : colle le lien de cette procédure et le résultat de la vérification finale, puis clos.

Historique. 1.0 du 15/10/2026 (M. Diallo) : création. 1.1 du 08/11/2026 (M. Diallo, relu par C. Lambert) : ajout de l'enregistrement DNS, des clés de l'équipe et des vérifications depuis le bastion.

Remarque comment chaque commande est complète et copiable, comment l'avertissement de l'étape 3 arrive avant l'action, et comment l'étape 6 vérifie la configuration avant de démarrer : une erreur se corrige plus facilement sur une VM éteinte. Les flux du pare-feu ne sont pas ouverts ici : c'est un autre changement, avec son propre circuit de validation (la matrice des flux de Sorbier).

Le compte rendu d'intervention

Le compte rendu d'intervention est le texte qui clôt une intervention sur un incident ou une demande. Il prouve ce qui a été fait, permet à un collègue de reprendre ou de refaire, alimente la base de connaissances et aide à repérer les pannes qui reviennent. Le référentiel du bloc 1 l'évalue explicitement : « le compte rendu d'intervention est clair et explicite ». Le cours ITIL et support détaille sa place dans le cycle du ticket ; voici ce qui fait sa qualité d'écriture.

Il répond toujours aux mêmes questions, dans cet ordre :

Le ticket 6 de la base parc sert d'exemple : Lucas Girard, à la logistique, signale le 22 septembre 2026 que son poste PC-0008 fait un bruit de ventilateur. Moussa Diallo intervient le lendemain. Voici ce qu'il aurait pu écrire, puis ce qu'il a écrit.

Avant. « Ventilo HS. Commandé. »

Après.

Ticket 6 : ventilateur bruyant. PC-0008 (HP ProDesk 400), Lucas Girard, Logistique, rez-de-chaussée.

Contexte. Bruit fort et continu depuis le 22/09 en début d'après-midi, signalé à 15 h 40. Le poste fonctionne normalement.

Diagnostic. Le 23/09 à 10 h 00, unité centrale ouverte : le bruit vient du ventilateur du processeur, dont le roulement est usé (bruit qui varie avec la vitesse de rotation) ; l'alimentation est silencieuse. Température du processeur relevée dans le BIOS : 48 °C, normale. Poste hors garantie (achat du 22/09/2020).

Actions. Ventilateur de remplacement commandé chez le fournisseur habituel, livraison annoncée sous 5 jours ouvrés.

Résultat. Problème non résolu à ce stade. Le poste reste utilisable sans risque en attendant la pièce.

Suite. Remplacer le ventilateur à réception de la pièce (20 minutes, poste éteint) ; prévenir M. Girard la veille. Ticket laissé en cours.

Temps passé. 15 min (M. Diallo).

Un collègue qui reprend le ticket la semaine suivante sait exactement où en est la panne, ce qui a été vérifié et ce qu'il doit faire. Et la commission de l'E5 lit dans ce texte une méthode de diagnostic, pas seulement un résultat.

Le rapport de test et la fiche de recette

Avant de mettre un service à disposition, on prouve qu'il fonctionne. Le cahier de recette liste les cas de test à passer, chacun avec ses données et son résultat attendu ; le rapport de test consigne ce qui a été obtenu ; le procès-verbal de recette acte la décision (accepté, accepté avec réserves, refusé). Le référentiel du bloc 1 attend qu'« un rapport de test du service » soit produit. La démarche complète, des critères d'acceptation aux cas de test, est dans le cours Tests ; voici la forme d'un rapport sur l'exemple du wiki.

Conclusion. 3 tests conformes sur 4. Le test T3 révèle une règle de pare-feu trop large sur l'interface VISITEURS ; correction demandée (ticket 31), puis T3 sera rejoué. Mise à disposition reportée jusqu'à ce que T3 soit conforme.

Un rapport honnête vaut mieux qu'un rapport parfait : un test non conforme, expliqué et corrigé, montre que tes tests servent à quelque chose.

Le rapport d'incident

Le rapport d'incident s'écrit après un incident qui a eu un impact important : coupure d'un service, perte de données, incident de sécurité. Il ne raconte pas seulement la réparation, comme le compte rendu : il explique pourquoi c'est arrivé et ce qui change pour que ça ne se reproduise pas.

Un exemple court, rédigé par Chloé Lambert :

Rapport d'incident : intranet inaccessible le 4 novembre 2026.

Résumé. De 9 h 10 à 10 h 25, les navigateurs ont refusé d'ouvrir l'intranet : son certificat TLS avait expiré à minuit. Aucun des 14 salariés n'a pu consulter les plannings pendant 1 h 15. Service rétabli ; incident clos.

Chronologie. 00 h 00 : expiration du certificat. 9 h 10 : premiers appels au support. 9 h 25 : cause identifiée (date d'expiration lue dans le navigateur). 10 h 15 : nouveau certificat émis par l'autorité de certification interne et installé. 10 h 25 : accès vérifié depuis trois postes.

Cause. Directe : le certificat n'a pas été renouvelé. Racine : son échéance n'était suivie nulle part ; la personne qui l'avait installé il y a deux ans a quitté l'entreprise, et la supervision ne contrôlait pas les dates d'expiration.

Actions préventives. Contrôle de l'expiration de tous les certificats dans Zabbix, alerte 30 jours avant (C. Lambert, 15/11). Inventaire des certificats dans GLPI avec leur date d'échéance (M. Diallo, 30/11). Procédure de renouvellement écrite et testée (M. Diallo, 30/11).

Note que la cause racine n'accuse personne : elle décrit un processus qui manquait. C'est le principe d'un retour d'expérience utile. Pour un incident de sécurité, le rapport suit la même logique mais ajoute les preuves, l'analyse et les éventuelles notifications obligatoires (rapport d'incident de sécurité).

L'argumentaire technique (note de choix)

L'argumentaire technique justifie le choix d'une solution devant un décideur : le besoin, les critères, les solutions comparées et la recommandation. Le référentiel du bloc 2 SISR le cite parmi les techniques de rédaction, et c'est le « dossier de choix » qu'attend la commission de l'E6. Deux indicateurs le visent : « le dossier de choix et l'argumentaire technique sont rédigés et prennent en compte des préoccupations éthiques et environnementales » et « les choix de solutions répondant au besoin exprimé […] sont décrits et justifiés en termes de coût, de délai et de qualité ». En SLAM, le même raisonnement répond à l'indicateur « le choix des composants logiciels à utiliser et/ou à développer est pertinent ».

Selon les entreprises, on parle de note de choix, d'étude comparative ou de note de décision ; la structure ne change pas.

Trois règles font la différence :

• Les critères avant les solutions. Fixe-les et pondère-les avec le décideur, puis note les solutions. Dans l'autre sens, on habille son outil préféré.
• Le coût total, pas le prix. Une solution libre n'est pas gratuite : il faut l'installer, la mettre à jour, la superviser, la sauvegarder et former l'équipe. C'est le coût total de possession, que le référentiel cite parmi les savoirs du bloc 2 SISR.
• L'éthique et l'environnement sont des critères comme les autres : licence et dépendance envers un éditeur, lieu d'hébergement des données (RGPD), réutilisation du matériel existant, sobriété de la solution (éco-conception).

Voici la note qu'a rédigée Moussa Diallo avant l'installation du wiki de Sorbier, à une date où la branche 2.5 de Wiki.js était encore sa version stable (les deux outils sont présentés au chapitre 6). Comme tout document destiné à un décideur, elle s'ouvre sur un résumé qui donne la recommandation.

Note de choix : l'outil du wiki interne. Version 1.0 du 01/10/2026. Rédigée par Moussa Diallo pour Antoine Mercier.

Résumé. Je recommande BookStack : il s'appuie sur MariaDB, que l'équipe maîtrise déjà, et sa structure en livres convient à des auteurs qui ne sont pas informaticiens. Wiki.js, plus souple, nous imposerait une migration vers PostgreSQL à sa prochaine version majeure.

Besoin. Les procédures du service informatique et les guides des salariés sont des fichiers Word éparpillés sur un partage : pas de recherche, des copies qui divergent. Il faut un outil où le service informatique écrit et où les 14 salariés lisent avec leur compte du domaine ; aucun budget de licence ; mise en service avant la fin de l'année.

Critères et solutions comparées. Critères et coefficients fixés avec Antoine avant l'étude ; notes sur 5 ; sources : documentation officielle des deux projets, consultée le 30/09/2026.

Critère	Coef.	BookStack	Wiki.js (branche 2.5)
Compatibilité avec l'existant et les compétences de l'équipe	3	5 : PHP et MariaDB ; MariaDB déjà maîtrisé	3 : MariaDB accepté, mais la version suivante n'acceptera plus que PostgreSQL, que l'équipe ne connaît pas
Prise en main par des auteurs non informaticiens	3	5 : structure imposée en étagères, livres, chapitres et pages	3 : arborescence libre, à organiser soi-même
Maturité et maintenance à venir	2	4 : versions régulières ; correctifs de sécurité fréquents, à appliquer	2 : fin de branche ; passage à la version 3 par export puis import
Coût total (installation, formation, maintenance)	2	4 : licence MIT, installation connue	3 : licence AGPL-3.0, migration à prévoir
Impact environnemental	1	4 : une petite VM sur l'hyperviseur existant	4 : idem
Total pondéré (sur 55)		50	32

Recommandation. BookStack, qui l'emporte sur les deux critères les plus lourds et ne nous engage dans aucune migration.

Risques et suites. Les correctifs de sécurité de BookStack sont fréquents : abonnement aux annonces de version et mise à jour mensuelle, avec une procédure écrite. Aucune dépendance envers un éditeur : licence libre, données dans notre propre base, export des pages en HTML, PDF ou Markdown. Suites : déploiement de la VM dans le VLAN 21 en octobre (PROC-INFRA-012), test par deux salariés, mise en production en novembre.

Le total pondéré additionne coefficient × note : pour BookStack, 3 × 5 + 3 × 5 + 2 × 4 + 2 × 4 + 1 × 4 = 50. Il ne décide pas seul : il rend le raisonnement visible et discutable. Chaque note est aussi justifiée dans sa case : une note sans raison ne prouve rien. L'exercice « Une grille de choix à terminer » du chapitre 6 applique la méthode au choix d'un générateur de site.

Exercices

Exercice 1 sur 4 L'en-tête qui manque Réussi À revoir

Chloé doit écrire la procédure « Renouveler le certificat TLS de l'intranet », à la suite de l'incident du 4 novembre. Le renouvellement redémarre le service web (coupure d'environ 30 secondes). Rédige uniquement l'en-tête et les rubriques qui précèdent les étapes : titre, suivi, objet, public et droits, prérequis, impact et durée, point de retour.

Voir la réponseMasquer la réponse de l'exercice 1

PROC-INFRA-015 : Renouveler le certificat TLS de l'intranet

Version 1.0 du 15/11/2026. Auteure : Chloé Lambert. Relecteur : Moussa Diallo. Statut : brouillon (à valider après un premier renouvellement réel).

• Objet. Remplacer le certificat TLS du site de l'intranet avant son expiration, avec un certificat émis par l'autorité de certification interne. Hors périmètre : la création de l'autorité elle-même.
• Public et droits. Technicien du service informatique ; accès administrateur au serveur de l'intranet et droit de demander un certificat à l'autorité interne.
• Prérequis. L'alerte Zabbix ou l'inventaire GLPI indique l'échéance ; le nom exact du site et ses noms alternatifs sont connus ; l'accès au serveur fonctionne.
• Impact et durée. Coupure d'environ 30 secondes au redémarrage du service web ; à faire entre 12 h 30 et 13 h 30 ou après 18 h, utilisateurs prévenus. Durée totale : 20 minutes.
• Point de retour. Copier l'ancien certificat et sa clé dans un dossier daté avant de les remplacer, pour pouvoir les remettre en cas d'erreur.

On attend surtout la fenêtre d'intervention (puisqu'il y a une coupure), la copie de l'existant et le statut brouillon tant que la procédure n'a pas été suivie une fois.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Un compte rendu à reprendre Réussi À revoir

Voici le compte rendu laissé dans le ticket 11 (« Accès VPN impossible », Sofiane Benali, commercial, poste PC-0004) : « Pb de certif. Fait le nécessaire. À voir. 35 min. » Liste ce qui manque, puis réécris-le. Les faits : le 20/10 à 9 h, Moussa a constaté dans les journaux du client VPN un message indiquant un certificat expiré ; il a vérifié que le certificat de l'utilisateur avait expiré le 19/10 ; il a demandé à Antoine, qui seul peut émettre les certificats VPN, d'en générer un nouveau.

Voir la réponseMasquer la réponse de l'exercice 2

Il manque : le contexte (qui, quel poste, depuis quand), la façon dont la cause a été établie, l'action réelle (« fait le nécessaire » ne dit rien), le résultat (résolu ou non ?), la suite (qui fait quoi, quand) et l'auteur du temps passé.

Ticket 11 : accès VPN impossible. PC-0004, Sofiane Benali, Commercial.

Contexte. Connexion VPN refusée depuis le 19/10 au soir, en déplacement.

Diagnostic. Le 20/10 à 9 h, le journal du client VPN indique un certificat expiré ; le certificat de l'utilisateur a expiré le 19/10. Le serveur VPN et les autres comptes fonctionnent : cause limitée à ce certificat.

Actions. Demande d'un nouveau certificat transmise à Antoine Mercier, seul habilité à les émettre.

Résultat. Non résolu : en attente du nouveau certificat.

Suite. Installer le certificat sur PC-0004 dès réception et tester une connexion avec M. Benali. Proposer d'ajouter l'échéance des certificats VPN à la supervision (même cause que l'incident de l'intranet).

Temps passé. 35 min (M. Diallo).

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 Remettre de l'ordre Réussi À revoir

Ces lignes viennent d'une procédure « Mettre à jour pfSense », mélangées. Remets-les dans l'ordre et dis quelle rubrique indispensable manque.

a. Vérifier dans Status > Dashboard que la nouvelle version est affichée et que les passerelles sont en ligne. b. Lancer la mise à jour depuis System > Update. c. Exporter la configuration depuis Diagnostics > Backup & Restore. d. Prévenir les utilisateurs de la coupure de 22 h à 22 h 30. e. Tester l'accès à Internet depuis un poste du VLAN 10 et le VPN depuis l'extérieur. f. Lire les notes de version de la nouvelle version.

Voir la réponseMasquer la réponse de l'exercice 3

L'ordre : f (lire les notes de version : changements incompatibles, prérequis), d (prévenir), c (sauvegarder la configuration, le point de retour), b (mettre à jour), a (contrôler le pare-feu lui-même), e (vérifier le service rendu aux utilisateurs).

Il manque le retour arrière : que faire si la mise à jour échoue ou casse un service (restaurer la configuration exportée, revenir à l'instantané de la VM pf1 pris avant l'opération). Il manque aussi un en-tête de suivi et les résultats attendus des étapes, mais le retour arrière est l'oubli le plus dangereux. Le cours pfSense détaille la sauvegarde et la mise à jour.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Conclure un rapport de test Réussi À revoir

Une recette de l'application de réservation des salles donne : T1 réserver une salle libre, conforme ; T2 réserver une salle déjà prise, l'application accepte la réservation (attendu : refus) ; T3 annuler sa réservation, conforme ; T4 annuler la réservation d'un autre salarié, refus (attendu : refus) ; T5 afficher le planning sur téléphone, conforme. Remplis le statut de T4, puis rédige la conclusion du rapport.

Voir la réponseMasquer la réponse de l'exercice 4

T4 est conforme : le refus était le résultat attendu. Un test qui vérifie un refus réussit quand le refus se produit.

Conclusion. 4 tests conformes sur 5. T2 est non conforme et bloquant : deux réservations de la même salle au même moment sont possibles, ce qui contredit la règle principale de l'application. Correction demandée, puis T2 rejoué, ainsi que T1 et T3 pour vérifier que la correction n'a rien cassé (non-régression). Mise à disposition reportée jusqu'à la correction.

Tu avais trouvé ?

Oui, j'avais bonPas encore