Vous avez repéré un sujet qui mérite d’être traité sur votre site. Vous avez peut-être déjà une documentation produit, quelques contenus internes ou simplement une idée assez précise de ce que vous aimeriez expliquer. De mon côté, je peux aussi trouver une partie des informations dans des sources publiques fiables.
Le travail ne consiste pas à rassembler tout ce qui existe sur le sujet pour en faire un article. Il faut surtout comprendre ce que votre lecteur cherche à savoir, vérifier ce qui peut l’être et repérer les informations qui dépendent vraiment de votre entreprise.
Quand vous me confiez un sujet cyber, je commence donc par le travailler de mon côté. Je reviens vers vos équipes si une précision me manque, si une information concerne directement votre produit ou si votre expérience apporte quelque chose que je ne peux pas trouver ailleurs. Vous n’avez pas à préparer tout le contenu avant que je puisse commencer.
Comprendre le sujet avant d’aller chercher des réponses en interne
Si vous me demandez un contenu sur l’EDR, je peux déjà avancer sans demander à l’un de vos experts de m’en expliquer les bases. Je vais chercher des sources techniques fiables, comprendre ce que fait ce type de solution et regarder les distinctions qui comptent pour le sujet que nous voulons traiter.
J’ai besoin de cette compréhension pour écrire correctement, mais aussi pour savoir quelles questions méritent éventuellement de vous être posées. Si je confonds deux notions proches ou si je ne comprends pas la portée d’une fonctionnalité, le risque n’est pas seulement d’employer le mauvais terme : tout le raisonnement du contenu peut partir dans une mauvaise direction.
Sur NIS2, je vais travailler autrement. Je commence par les textes applicables et les ressources institutionnelles, parce que ce sont eux qui permettent d’établir ce que prévoit réellement le cadre réglementaire. Votre propre discours sur NIS2 pourra ensuite avoir sa place si le contenu doit présenter votre accompagnement ou répondre à une question liée à votre offre.
Vous n’avez donc pas besoin de mobiliser quelqu’un pour refaire avec moi un travail de documentation que je peux mener en amont. Si je reviens vers vous, la discussion peut porter sur un point beaucoup plus précis.
C’est ce que montrent déjà mes démonstrations consacrées à l’EDR ou à NIS2. Vous pouvez y voir la manière dont je pose le contexte, les notions que je prends le temps d’expliquer et le niveau de détail que je retiens pour un lecteur professionnel qui n’est pas spécialiste du sujet.
Distinguer ce qui peut être documenté de ce qui doit être confirmé
La recherche finit parfois par rencontrer une limite très concrète : certaines informations appartiennent à votre entreprise.
Je peux, par exemple, documenter le fonctionnement général d’un EDR. Si votre contenu doit expliquer comment votre propre solution traite un comportement suspect ou ce que vos équipes constatent lors de certains déploiements, je ne vais pas essayer de le déduire à partir de sources extérieures.
Dans ce cas, je reviens vers vous avec la question qui reste ouverte. La réponse se trouve peut-être déjà dans une documentation produit que vous pouvez me transmettre. Quelques lignes écrites peuvent aussi suffire. Un échange oral devient utile lorsque la réponse demande davantage de contexte ou lorsqu’il est simplement plus facile pour votre expert de l’expliquer directement.
Cette intervention dépend donc vraiment du sujet. Un contenu pédagogique sur une technologie bien documentée peut avancer presque entièrement à partir de recherches externes. Si vous voulez faire entendre une expérience propre à votre entreprise ou expliquer une particularité de votre solution, votre expertise interne prend naturellement davantage de place.
Organiser l’information pour construire un contenu clair
Même avec de bonnes sources et les bonnes informations, un article peut rester difficile à lire. Vous le voyez probablement dans certaines documentations techniques : les informations sont précises, mais il faut déjà bien connaître le sujet pour suivre.
Une précision peut être exacte et pourtant arriver trop tôt dans l’article. Un terme mérite parfois d’être expliqué pour un dirigeant, alors qu’un responsable cybersécurité n’aura pas besoin de cette parenthèse. Le choix dépend moins de la quantité d’informations disponibles que de la personne à laquelle le contenu s’adresse.
Prenons un contenu sur l’EDR destiné à un décideur qui connaît encore mal cette technologie. Je pourrais commencer par détailler la collecte de télémétrie ou les mécanismes d’analyse puisque ces informations sont faciles à documenter. Mais si ce lecteur essaie surtout de comprendre pourquoi un EDR lui apporterait autre chose qu’un antivirus, il vaut mieux partir de cette question. Les explications plus techniques viendront aux endroits où elles l’aident à comprendre la différence.
C’est aussi pour cette raison qu’une bonne documentation produit ne devient pas automatiquement un bon article. Elle répond à son propre usage. Si nous nous adressons à un prospect qui découvre le sujet, certaines explications devront prendre plus de place et d’autres pourront rester en retrait.
Je sélectionne la matière qui sert réellement le sujet, je décide où une explication est nécessaire et je construis le texte pour que le lecteur puisse avancer sans avoir à maîtriser le sujet au préalable.
Le choix du format vient avec cette réflexion. Je regarde d’abord ce que vous voulez transmettre, à qui vous vous adressez et ce que le contenu doit permettre de comprendre ou de trouver. Le bon format se décide ensuite.
Vous pouvez observer ces arbitrages dans mes démonstrations cyber. Regardez par exemple l’ordre dans lequel les notions sont introduites, les détails techniques qui sont expliqués et ceux qui restent volontairement en arrière-plan. Ce sont aussi ces décisions qui rendent un sujet technique lisible pour quelqu’un qui ne travaille pas avec lui tous les jours.
Faire valider les points qui ne peuvent pas l’être autrement
Les informations que j’ai établies à partir de sources fiables restent vérifiées de mon côté. En revanche, lorsqu’un passage concerne directement votre produit, une pratique interne ou une observation de vos équipes, je vous le soumets pour validation.
Si je décris une fonctionnalité de votre solution ou si je reprends une observation issue de vos équipes, la personne concernée doit pouvoir vérifier que ce que j’ai écrit correspond bien à la réalité. Elle peut me signaler qu’une formulation technique manque de précision ou qu’un passage décrit mal le comportement du produit. Je reprends ensuite le texte sans lui demander de retravailler l’article dans son ensemble.
Selon le contenu, cette validation peut être très légère ou demander davantage d’échanges. Un article construit principalement à partir de sources publiques n’aura pas les mêmes besoins qu’une ressource qui présente votre approche, votre technologie ou un retour d’expérience interne.
Vos équipes restent ainsi concentrées sur ce qu’elles connaissent le mieux, tandis que je prends en charge la recherche, les choix éditoriaux et la rédaction nécessaires pour transformer le sujet en un contenu clair et publiable.