Hopwise Labs
Hopwise Labs
Demander un pilote
Blog

Des guides pour les équipes d’exploitation.

Des guides courts et sourcés pour les équipes qui exploitent des datacenters, des réseaux et des hébergements. Chacun part d’un problème de terrain et dit ce qui reste à la main.

13 étapesmis à jour le 21 octobre 2026

  1. 01CapacitéÀ la uneDCIM datacenter : ce qu’il fait, ce qu’il laisse à la mainDCIM datacenter : ce que l’outil tient (espace, énergie, froid, câblage), ce qui reste à la main autour de lui, et comment compter la capacité restante.21 octobre 20267 min de lectureLire le guide
  2. 02ÉtudeExploitation d’infrastructure : ce que Google France afficheDix requêtes d’exploitation relevées sur Google France le 21 octobre 2026 : 55 % d’éditeurs, 20 % en anglais, presque aucun guide de terrain.7 min de lectureLire
  3. 03AutomatisationAutomatisation IT : un script d’abord, un agent sur le resteAutomatisation IT en entonnoir : des scripts pour ce qui suit une règle, un agent sur le seul résidu ambigu, une validation humaine et un journal.7 min de lectureLire
  4. 04MaintenancesAvis de maintenance : prévenir chaque client touchéAvis de maintenance : déduire les clients touchés de l’inventaire, pas de la mémoire. Périmètre, contenu, préavis, envoi tracé et ce qu’on mesure après.6 min de lectureLire
  5. 05Source de véritéCMDB : définition, et comment la tenir à jourCMDB : définition, pourquoi elle devient fausse, et comment la tenir à jour en rapprochant le déclaré, le découvert et le supervisé.7 min de lectureLire
  6. 06Source de véritéNetBox, source de vérité : ce qu’il tient, ce qu’il laisseNetBox comme source de vérité d’un opérateur : ce qu’il modélise, ce qu’il ne fait pas, comment le tenir juste et ce qui reste à la main autour.7 min de lectureLire
  7. 07InterfacesPortail client : ce qu’un opérateur doit y montrerPortail client d’opérateur : demandes, interventions, capacité, incidents et maintenances, lus dans vos outils au lieu d’être recopiés à la main.7 min de lectureLire
  8. 08IncidentsPost-mortem d’incident : une chronologie tirée des outilsPost-mortem d’incident : une chronologie tirée des traces des outils, un format sans recherche de coupable, des actions suivies jusqu’à leur clôture.6 min de lectureLire
  9. 09Source de véritéCartographie du SI : pourquoi elle est fausse six mois aprèsUne cartographie du SI se périme dès qu’on la termine, sauf si l’exploitation la produit. Comment la tenir à jour et vérifier qu’elle l’est.5 min de lectureLire
  10. 10ExploitationMCO informatique : le maintien en conditions opérationnellesMCO informatique : quatre activités, les indicateurs qui disent la vérité et les traces qui prouvent que le maintien en conditions est tenu.5 min de lectureLire
  11. 11IncidentsMTTR : le mesurer honnêtement avant de vouloir le réduireQuatre définitions pour un même sigle, deux bornes à fixer, et pourquoi la moyenne ment. Un temps de rétablissement que vos clients peuvent vérifier.5 min de lectureLire
  12. 12NIS2NIS2 : qui est concerné ? Le test en trois questionsSecteur, taille, cas particuliers : trois questions pour savoir si votre organisation entre dans NIS2, et si elle est essentielle ou importante.6 min de lectureLire
  13. 13NIS2Notification d’incident NIS2 : 24 heures, 72 heures, un moisLe calendrier de l’article 23, ce que chaque échéance exige de l’exploitation, et le circuit qui tient les délais sans refaire la chronologie de mémoire.6 min de lectureLire
Arrivée

Ces guides décrivent le travail. Nous le construisons.

Source de vérité, intégrations, circuits d’incident, interfaces, automatisation : nous construisons ce qui manque, dans votre système. Dites où vous en êtes.

Décrire ma situationOu télécharger le modèle de post-mortem (PDF)