Réparer son serveur et son assistant en panne, sans paniquer (le carnet de pannes)
Personne ne le dit quand on lance son activité avec des outils en ligne : ça tombe en panne. Pas par malchance, par nature. Un serveur, un assistant connecté, un automatisme qui tourne tout seul, tout ça finit par casser un jour. Et le vrai danger, ce n'est pas la panne, c'est la panique : on touche à tout en même temps, on change cinq choses d'un coup, et on transforme une petite panne en catastrophe.
Cette masterclass vous donne la méthode complète pour réparer un outil en panne sans paniquer : un constat clair avant de toucher quoi que ce soit, un diagnostic dans le bon ordre, et un carnet de pannes qui fait que la prochaine panne identique se règle en lisant, pas en cherchant.
Ce que cet exercice ne peut pas casser
L'exercice se fait à froid, dans une simple note, sur une panne déjà réparée. Vous ne touchez à aucun serveur, vous ne redémarrez rien, vous ne supprimez rien. Au pire, vous obtenez une fiche incomplète que vous enrichirez à la prochaine panne : c'est exactement comme ça qu'un carnet de pannes se construit.
Ce que vous saurez faire à la fin
- Poser un constat de panne clair (quel outil, quel message exact, depuis quand) avant de toucher quoi que ce soit.
- Chercher la cause dans le bon ordre, du plus simple au plus probable, sans rien casser au passage.
- Transformer chaque panne réparée en fiche réutilisable : symptôme, cause, geste qui a marché, pièges.
- Niveau membre· le prompt prêt à coller qui transforme votre récit de panne, même raconté en vrac, en fiche de carnet de pannes propre et réutilisable.
- Niveau Pro· mon vrai arbre de diagnostic de serveur, dans l'ordre exact où je le déroule, avec les vrais signes qui disent où regarder.
Trois gestes dans l'ordre : on constate, on diagnostique, on note. Jamais l'inverse.
Les trois gestes qui réparent vraiment
La parade contre la panique tient en une phrase : on ne devine pas, on diagnostique. Diagnostiquer veut dire chercher la cause avec méthode, dans un ordre précis, comme un médecin qui pose des questions avant de prescrire. C'est moins excitant que de bidouiller. Mais c'est ce qui répare vraiment.
1Le calme avant la commandedoute : « noter au lieu de réparer, n'est-ce pas du temps perdu ? »
Avant de toucher quoi que ce soit, écrivez une photo claire de la panne. Trois choses suffisent : quel outil est touché, quel message exact s'affiche (recopiez-le mot pour mot, même si vous ne le comprenez pas), et depuis quand. Dans la précipitation, on agit sur des suppositions : on change cinq choses d'un coup, et même si ça remarche, on ne sait plus laquelle a réparé. Pire, on casse autre chose au passage. Le jour où mon assistant à distance a cessé de répondre, mon constat tenait en une ligne : j'écris à mon assistant dans ma messagerie, il ne répond pas, et ses traces internes affichent un compteur à zéro. Cette ligne m'a tout dit, plus tard, sur où chercher. Un constat clair, c'est la moitié de la réparation.
2Le diagnostic dans le bon ordredoute : « par où commencer quand tout semble cassé ? »
Posez les questions dans l'ordre, de la plus basique à la plus précise : la machine répond-elle (un simple test de présence) ? Est-elle joignable de l'extérieur ? L'outil est-il bien démarré ? Est-il bien connecté avec ses identifiants ? La plupart des gens commencent par le plus compliqué, parce que c'est ce qui leur fait peur. Erreur : neuf fois sur dix, la cause est plus bête que prévu. En partant du bas, on élimine vite les fausses pistes. Ce jour-là, j'ai écarté une à une un automatisme parasite, un conflit entre deux copies du même outil, un problème de réseau, avant de tomber sur la vraie cause : mon assistant n'était plus connecté avec son identifiant. Le signe qui ne trompe pas : son compteur d'activité restait à zéro. Quand ce compteur est à zéro, ce n'est jamais un problème de réseau ni de message, c'est toujours un problème de connexion.
3Le carnet de pannesdoute : « c'est réparé, à quoi bon écrire ? »
Une panne réparée et oubliée, c'est une panne que vous re-paierez plein tarif la fois suivante. Une panne réparée et notée, c'est un acquis pour toujours. Dès que c'est réparé, écrivez la fiche : trois colonnes suffisent. Le symptôme (ce qu'on voit), la cause (ce qui clochait vraiment), le geste qui a marché (les actions exactes, dans l'ordre). Ajoutez une section que j'appelle les pièges qui m'ont coûté du temps : les fausses pistes que vous avez suivies, pour ne pas les re-suivre. Mon carnet à moi commence par le piège le plus fréquent, avec sa solution en quatre étapes. La prochaine panne identique se règle en lisant, pas en cherchant.
À vous de jouer : votre première fiche de carnet
Prenez la dernière panne que vous avez vécue et réparée, même toute petite (un outil qui ne s'ouvrait plus, un automatisme qui ne partait plus). Ouvrez une note vide et écrivez la fiche, section par section.
Le résultat, en 30 secondes
Voici le genre de fiche qu'on obtient avec le prompt, à partir d'un simple récit en vrac. Imaginons une formatrice en ligne dont l'assistant connecté à sa messagerie a cessé de répondre :
FICHE. L'assistant ne répond plus dans la messagerie. Le fix le plus fréquent : symptôme, l'assistant reçoit bien les messages mais ne répond jamais, et son compteur d'activité reste à zéro. Cause quasi-toujours : la connexion de l'assistant a expiré après un redémarrage. Réparer : 1) sur l'ordinateur principal, régénérer le jeton de connexion. 2) sur le serveur, remplacer l'ancien jeton par le nouveau dans le fichier de configuration (remplacer, ne pas en ajouter un deuxième). 3) redémarrer le service de l'assistant. 4) envoyer un message et vérifier que le compteur passe au-dessus de zéro. Piège numéro un : l'assistant qui répond quand on le teste à la main n'est PAS forcément connecté. Le seul juge fiable, c'est le compteur d'activité au-dessus de zéro. Trois mois plus tard, même panne : la formatrice ouvre la fiche, suit les quatre étapes, et c'est réglé avant son café.
Le prompt prêt à coller
Tu es mon assistant de documentation technique. Je viens de réparer une panne sur un de mes outils. Aide-moi à en faire une fiche de carnet de pannes, claire et réutilisable, pour que la prochaine fois soit rapide. Voici mon récit de ce qui s'est passé (symptôme, ce que j'ai testé, ce qui a fini par marcher) : [RACONTEZ ICI, MÊME EN VRAC, CE QUI A CASSÉ ET COMMENT VOUS L'AVEZ RÉPARÉ] Produis une fiche avec ces sections, dans cet ordre : 1. Le fix le plus fréquent (résumé en quelques lignes : symptôme, cause quasi-toujours, et les étapes exactes pour réparer, numérotées).
Vous venez de réparer quelque chose ? Avant d'oublier, le prompt transforme votre récit de la panne, même raconté en vrac, en fiche de carnet propre : le fix le plus fréquent, l'ordre de diagnostic en tableau, les pièges qui vous ont coûté du temps. Laissez votre email, je vous l'envoie pour écrire votre première fiche.
Vérifiez que c'est à vous
Votre assistant connecté reçoit bien vos messages mais ne répond jamais, et son compteur d'activité reste à zéro. Quelle est votre lecture ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez à un proche, en une phrase, pourquoi on ne touche à rien avant d'avoir noté le symptôme exact d'une panne. Si vous savez le dire simplement, le réflexe est à vous.
Ce que vous savez faire maintenant
- Devant une panne, noter d'abord le symptôme exact (outil, message mot pour mot, depuis quand) au lieu de tout toucher.
- Chercher la cause dans l'ordre, du plus simple au plus probable, et repérer le signe qui dit où est vraiment le problème.
- Une fois réparé, écrire la fiche (symptôme, cause, geste, pièges) pour que la panne identique se règle en lisant le carnet.
On ne devine pas, on diagnostique.
Continuez seul
Vous avez tout pour écrire votre première fiche. Étape suivante du parcours :
Épisode 41 : Produire 186 contenus en une nuit avec des agents en parallèle →Faites-le avec moi
Au niveau Pro, je vous donne mon vrai arbre de diagnostic de serveur, dans l'ordre exact où je le déroule, avec les vrais signes qui disent où regarder. C'est la méthode qui m'a fait passer d'un serveur à terre pendant treize jours à une réparation en une seule action.