Rendre une intervention de maintenance vérifiable par le client lui-même

Le contexte

La maintenance d’un poste de travail souffre d’un défaut structurel de confiance. Le technicien intervient, la machine va mieux, et le client doit croire sur parole que le travail a été fait sérieusement. Il ne dispose d’aucun moyen de le vérifier, ce qui place toute la relation sur la seule réputation.

J’ai construit cet outil pour supprimer ce point aveugle.

Le problème

Deux besoins qui semblent contradictoires.

Le technicien a besoin de détail : ce qui a été analysé, ce qui a été modifié, ce qui a échoué et pourquoi.

Le client a besoin de sens : ce qui n’allait pas, ce qui a été corrigé, ce qu’il doit surveiller. Lui livrer le rapport technique revient à ne rien lui livrer du tout.

La réponse évidente, écrire le second rapport à la main après chaque intervention, ne tient pas : c’est la première chose que je sacrifie quand je suis pressé.

Les contraintes

• Aucune dépendance externe à l’exécution. L’outil doit tourner sur un poste client sans rien installer, sans accès à un dépôt de paquets, sans connexion sortante particulière.
• Windows PowerShell 5.1 uniquement, l’édition présente d’origine sur les postes Windows, et la seule qui porte l’interface graphique native utilisée ici.
• Un mode qui ne modifie rien, pour pouvoir constater avant d’agir.
• Des droits administrateur, donc un outil qu’il faut concevoir comme dangereux par nature.

Mon intervention

Conception, développement, tests, documentation et distribution sous ma marque.

L’architecture

L’outil enchaîne dix-sept modules de maintenance indépendants, couvrant le nettoyage, l’intégrité du système, le réseau, le disque et le démarrage. Chaque module est autonome et peut être exécuté seul, ce qui permet de cibler un symptôme précis au lieu de tout relancer.

Un orchestrateur en ligne de commande porte l’exécution scriptée ou planifiée. Une interface graphique se pose par-dessus le même moteur, sans le dupliquer. Un lanceur choisit automatiquement l’un ou l’autre selon la manière dont il est appelé, et exige les droits administrateur.

À la fin de chaque exécution, l’outil écrit deux rapports HTML autoportants partageant le même identifiant de session : un rapport technique détaillé, et un rapport client vulgarisé, livrable tel quel. Les deux décrivent la même exécution avec deux niveaux de lecture.

Les choix techniques

Zéro dépendance au moment de l’exécution. Aucun module externe, aucun paquet à récupérer. C’est une contrainte forte, qui interdit certaines facilités d’écriture, mais elle garantit que l’outil fonctionne sur un poste isolé, en clientèle, sans préparation. Un outil de dépannage qui a besoin d’Internet pour démarrer est inutile précisément le jour où le réseau est en cause.

Des rapports autoportants, en un seul fichier, sans ressource externe. Ils s’ouvrent sur n’importe quel poste, s’archivent, et s’envoient par courriel sans se casser.

Un mode audit en lecture seule, qui force la simulation de toutes les opérations. Il permet de montrer au client ce qui serait fait avant de le faire, ce qui change la nature de la conversation commerciale.

Des codes de sortie distincts selon qu’il n’y a eu aucun problème, au moins un avertissement, au moins une erreur, ou un échec d’initialisation. C’est ce qui rend l’outil exploitable dans une planification automatique.

La sécurité

Cet outil s’exécute avec les droits administrateur sur un poste client.

Le mode audit force la simulation, ce qui rend l’inspection sans effet de bord possible par construction. Le code est vérifié par un analyseur statique et couvert par des tests. Les rapports sont écrits localement, et l’outil n’envoie rien vers l’extérieur : ce qui est constaté sur le poste du client reste chez le client.

Le résultat

L’outil est fonctionnel et distribué sous ma marque, avec sa documentation et son journal des évolutions. Il sert à industrialiser une prestation que je réalisais auparavant à la main.

Ce que ce projet démontre

Le double rapport est le vrai sujet. J’ai codé la vulgarisation dans l’outil pour qu’elle ne dépende plus de ma disponibilité au moment de la livraison.

C’est une constante de ma manière de travailler, visible dès mes premières missions en 2015, quand je remettais des procédures illustrées après chaque installation. Aujourd’hui, cette habitude est devenue une fonctionnalité de l’outil.