<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Hopwise Labs · Blog</title>
    <link>https://hopwiselabs.fr/blog</link>
    <description>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.</description>
    <language>fr-FR</language>
    <lastBuildDate>Wed, 21 Oct 2026 00:00:00 GMT</lastBuildDate>
    <atom:link href="https://hopwiselabs.fr/blog/feed.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Exploitation d’infrastructure : ce que Google France affiche</title>
      <link>https://hopwiselabs.fr/blog/etude-serp-exploitation-2026</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/etude-serp-exploitation-2026</guid>
      <pubDate>Wed, 21 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Étude</category>
      <description>Le 21 octobre 2026, nous avons relevé la première page de Google France sur dix requêtes d’exploitation d’infrastructure, soit 83 résultats organiques. 55 % viennent d’éditeurs de logiciels. Sur neuf requêtes sur dix, aucun résultat n’est un guide de terrain en français écrit pour un opérateur. Les dix pages affichent une réponse générée par Google.</description>
    </item>
    <item>
      <title>Automatisation IT : un script d’abord, un agent sur le reste</title>
      <link>https://hopwiselabs.fr/blog/automatiser-exploitation</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/automatiser-exploitation</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Automatisation</category>
      <description>L’automatisation IT confie à un programme une tâche d’exploitation répétitive qu’une personne faisait à la main. Elle fonctionne en entonnoir : un script pour tout ce qui suit une règle, un agent seulement sur le résidu ambigu, une validation humaine avant toute écriture et un journal de chaque décision. Commencez par une tâche fréquente et mesurable, pas par une plateforme.</description>
    </item>
    <item>
      <title>Avis de maintenance : prévenir chaque client touché</title>
      <link>https://hopwiselabs.fr/blog/maintenance-planifiee-clients</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/maintenance-planifiee-clients</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Maintenances</category>
      <description>Un avis de maintenance prévient chaque client touché par une intervention planifiée : fenêtre et fuseau horaire, services concernés, impact attendu, action à prévoir, contact pendant la fenêtre. La liste des destinataires se déduit de l’inventaire, des équipements jusqu’aux contrats, puis une seconde personne la valide. Le préavis est celui du contrat le plus exigeant.</description>
    </item>
    <item>
      <title>CMDB : définition, et comment la tenir à jour</title>
      <link>https://hopwiselabs.fr/blog/cmdb-a-jour</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/cmdb-a-jour</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Source de vérité</category>
      <description>Une CMDB (configuration management database) est la base qui recense les éléments de configuration d’un système d’information, leurs attributs et leurs relations. Elle reste juste si chaque changement la met à jour et si un rapprochement régulier la confronte à la découverte et à la supervision, avec une source qui fait foi par attribut et un responsable par classe.</description>
    </item>
    <item>
      <title>DCIM datacenter : ce qu’il fait, ce qu’il laisse à la main</title>
      <link>https://hopwiselabs.fr/blog/dcim-datacenter</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/dcim-datacenter</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Capacité</category>
      <description>Un DCIM datacenter (data center infrastructure management) est le logiciel qui décrit l’infrastructure physique d’un datacenter : espace, énergie, froid, câblage et actifs. Il ne mesure rien seul et ne sait pas ce qui tourne sur les équipements. Retenez trois règles : un auteur par donnée, un rapprochement régulier avec le terrain, une capacité restante calculée axe par axe.</description>
    </item>
    <item>
      <title>NetBox, source de vérité : ce qu’il tient, ce qu’il laisse</title>
      <link>https://hopwiselabs.fr/blog/netbox-source-de-verite</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/netbox-source-de-verite</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Source de vérité</category>
      <description>NetBox est un logiciel libre qui sert de source de vérité à une infrastructure réseau et physique : sites, baies, câblage, alimentation, circuits, adresses IP. Il décrit l’état voulu, pas l’état observé : il ne découvre pas, ne supervise pas et ne pousse pas de configuration. Il reste juste avec un auteur par donnée et un rapprochement régulier.</description>
    </item>
    <item>
      <title>Portail client : ce qu’un opérateur doit y montrer</title>
      <link>https://hopwiselabs.fr/blog/portail-client-operateur</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/portail-client-operateur</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Interfaces</category>
      <description>Un portail client d’opérateur est un espace authentifié où chaque client voit ses demandes, ses interventions, ses ressources réservées, les incidents et maintenances qui le touchent, ses documents. Il lit ces données dans l’inventaire, l’outil de tickets et la supervision au lieu de les recopier, filtre côté serveur sur le client connecté et se juge aux relances évitées.</description>
    </item>
    <item>
      <title>Post-mortem d’incident : une chronologie tirée des outils</title>
      <link>https://hopwiselabs.fr/blog/post-mortem-incident</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/post-mortem-incident</guid>
      <pubDate>Tue, 20 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Incidents</category>
      <description>Un post-mortem d’incident est le document écrit après un incident pour établir ce qui s’est passé, pourquoi, et ce qui change. Sa chronologie se tire des traces horodatées des outils (supervision, astreinte, tickets, changements), pas de la mémoire. Il décrit des causes sans désigner de coupable, et chaque action corrective devient un ticket avec propriétaire et échéance.</description>
    </item>
    <item>
      <title>Cartographie du SI : pourquoi elle est fausse six mois après</title>
      <link>https://hopwiselabs.fr/blog/cartographie-si-a-jour</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/cartographie-si-a-jour</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Source de vérité</category>
      <description>La cartographie du SI décrit les composants d’un système d’information, leurs relations, leurs responsables et les services qui en dépendent, en vues métier, applicative et infrastructure. Elle ne reste vraie que si l’exploitation la produit : chaque changement passe par l’inventaire, chaque alerte et chaque incident s’y rattachent, et chaque modification est datée.</description>
    </item>
    <item>
      <title>MCO informatique : le maintien en conditions opérationnelles</title>
      <link>https://hopwiselabs.fr/blog/mco-maintien-en-conditions-operationnelles</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/mco-maintien-en-conditions-operationnelles</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Exploitation</category>
      <description>Le MCO informatique, ou maintien en conditions opérationnelles, regroupe les actions qui garantissent qu’une infrastructure continue de rendre le service attendu, au niveau attendu, de la mise en service au retrait. Il couvre quatre activités : préventif, correctif, évolutif et suivi. Il se prouve par quatre indicateurs : disponibilité, MTTR, dette d’obsolescence, taux de changements réussis.</description>
    </item>
    <item>
      <title>MTTR : le mesurer honnêtement avant de vouloir le réduire</title>
      <link>https://hopwiselabs.fr/blog/mttr-mesurer-honnetement</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/mttr-mesurer-honnetement</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>Incidents</category>
      <description>Le MTTR (mean time to recover, repair, resolve ou respond) mesure le temps moyen de rétablissement après un incident. Le sigle recouvre quatre définitions : écrivez laquelle vous utilisez, fixez le départ (détection) et l’arrivée (service rétabli), sourcez chaque horodatage dans les outils, et lisez la médiane et le 90e centile par gravité plutôt que la moyenne.</description>
    </item>
    <item>
      <title>NIS2 : qui est concerné ? Le test en trois questions</title>
      <link>https://hopwiselabs.fr/blog/nis2-qui-est-concerne</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/nis2-qui-est-concerne</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>NIS2</category>
      <description>Les entités concernées par NIS2 sont celles des secteurs des annexes I et II de la directive (UE) 2022/2555, au moins de taille moyenne : 50 personnes ou plus, ou plus de 10 millions d’euros de chiffre d’affaires et de bilan. Certains services numériques le sont sans condition de taille. Les fournisseurs des entités concernées en reçoivent les exigences par contrat.</description>
    </item>
    <item>
      <title>Notification d’incident NIS2 : 24 heures, 72 heures, un mois</title>
      <link>https://hopwiselabs.fr/blog/notification-incident-nis2</link>
      <guid isPermaLink="true">https://hopwiselabs.fr/blog/notification-incident-nis2</guid>
      <pubDate>Mon, 19 Oct 2026 00:00:00 GMT</pubDate>
      <dc:creator>Chrif Toujeni</dc:creator>
      <category>NIS2</category>
      <description>La notification d’incident NIS2 suit trois échéances fixées par l’article 23 de la directive (UE) 2022/2555 : une alerte précoce dans les 24 heures après la prise de connaissance d’un incident important, une notification d’incident dans les 72 heures, puis un rapport final un mois après cette notification. Le délai part de la détection, pas du diagnostic.</description>
    </item>
  </channel>
</rss>
