Compétence technique
Documentation technique
Garantir la transmission du savoir et la pérennité du système d'information.
Ma définition
La documentation technique est ce qui transforme une intervention ponctuelle en capital collectif. Un déploiement réussi sans documentation produit une dépendance : si l'ingénieur qui a conçu le système n'est plus disponible, la connaissance disparaît avec lui. Une bonne documentation, au contraire, rend n'importe quel membre de l'équipe capable d'intervenir, de comprendre l'architecture, et de résoudre les problèmes sans dépendre d'une personne spécifique.
Dans un environnement comme Criteo, où les projets s'enchaînent et les équipes évoluent, la documentation n'est pas une tâche annexe : c'est un livrable à part entière. Un DAT rédigé correctement vaut autant qu'une configuration correctement déployée.
Points clés
Capital collectif
Un déploiement réussi sans documentation produit une dépendance. Une bonne doc rend n'importe quel membre de l'équipe capable d'intervenir sans dépendre d'une personne spécifique.
Livrable à part entière
Dans un environnement où les projets s'enchaînent et les équipes évoluent, la documentation n'est pas une tâche annexe : un DAT bien rédigé vaut autant qu'une config bien déployée.
Référence opérationnelle
L'objectif d'un DAT : qu'un membre de l'équipe qui n'a pas participé au déploiement puisse comprendre l'architecture et intervenir sans être guidé.
Mes éléments de preuve
Extension réseau →
Pour l'Innovation Hub, j'ai rédigé un DAT complet couvrant la topologie réseau, les décisions d'architecture, les VLANs, les flux d'authentification et les conditions de rollback, accompagné de schémas Lucidchart. L'objectif était qu'un membre de l'équipe qui n'a pas participé au déploiement puisse comprendre l'architecture et intervenir sans être guidé. Ce DAT sert aujourd'hui de référence pour les futurs déploiements d'étages chez Criteo.
Lab staging →
J'ai structuré la documentation du Lab dans Confluence, avec des pages dédiées aux tests de nouvelles features, d'ajout d'équipements et de configurations. Chaque test significatif est documenté avec son contexte, ses résultats et ses points de vigilance, lié à la page principale Meraki de l'équipe. Le but est que n'importe qui puisse utiliser le Lab efficacement sans dépendre de ma disponibilité.
Centralisation parc →
J'ai rédigé un article de Knowledge Base documentant toute notre utilisation de ServiceNow et surtout comment ajouter de la donnée pour les prochains ajouts de matériels. J'ai aussi produit des pages de suivi de réalisation pour que chaque incident significatif qu'on a rencontré devienne un capital de connaissance partagé plutôt qu'une information perdue une fois le ticket fermé.
Points clés
DAT complet avec rollback
Topologie, décisions d'architecture, VLANs, flux d'authentification et conditions de rollback documentés, schémas Lucidchart inclus.
Documentation Lab dans Confluence
Pages dédiées par test, résultats et points de vigilance, liés à la page principale Meraki de l'équipe pour une navigation centralisée.
KB ServiceNow et suivi de réalisation
Article de Knowledge Base couvrant l'utilisation de ServiceNow et les processus d'ajout, plus pages de suivi transformant chaque incident significatif en capital partagé.
Autocritique
Le défi constant est de maintenir la documentation à jour après chaque modification. La tendance naturelle est de prioriser le déploiement sur la mise à jour du DAT, ce qui crée une dette documentaire qui s'accumule. J'ai mis en place une règle personnelle : aucun ticket ne passe en "fermé" sans que la KB correspondante soit mise à jour si l'incident a révélé quelque chose de nouveau.
L'autre limite : mes documents sont détaillés sur le "quoi" et le "comment", moins toujours sur le "pourquoi" des choix d'architecture. C'est souvent le plus utile pour un ingénieur qui reprend le projet, et c'est l'axe que je travaille à améliorer.
La documentation n'a jamais été ma priorité naturelle, elle s'est construite par discipline imposée, pas par réflexe spontané, et ça se ressent encore sur les petits sujets. Dans mon profil d'ingénieur réseau, c'est une compétence utile mais secondaire : elle soutient le reste, elle ne le définit pas.
Points clés
Dette documentaire
La tendance naturelle est de prioriser le déploiement sur la mise à jour du DAT. Règle personnelle mise en place : aucun ticket "fermé" sans KB mise à jour si l'incident a révélé quelque chose de nouveau.
Le "pourquoi" sous-documenté
Mes documents sont détaillés sur le "quoi" et le "comment", moins toujours sur le "pourquoi" des choix d'architecture. C'est souvent le plus utile pour un ingénieur qui reprend le projet.
Mon évolution
Je m'intéresse aux approches de documentation "as code" via Markdown et Git, qui permettent de versionner la documentation au même titre que le code et de détecter les dérives entre la doc et la réalité du système. C'est la direction que prennent les équipes qui gèrent des infrastructures complexes à grande échelle, et c'est cohérent avec ma trajectoire NetDevOps.
En pratique, je versionne déjà mes propres notes et schémas d'architecture en Markdown sur Git. L'objectif à court terme est de migrer la documentation du Lab réseau vers ce format pour qu'elle soit aussi traçable que le code.
Points clés
Documentation as code
Markdown et Git pour versionner la documentation au même titre que le code et détecter les dérives entre la doc et la réalité du système.
Cohérence avec la trajectoire NetDevOps
La doc as code est la direction des équipes qui gèrent des infrastructures complexes à grande échelle : cohérente avec l'objectif d'ingénieur réseau/automation.
Réalisations rattachées
Cette compétence s'est exprimée principalement au travers des projets suivants :
Points clés
Extension réseau zéro-coupure
DAT complet avec topologie, VLANs, flux d'authentification, conditions de rollback et schémas Lucidchart.
Lab réseau
Documentation Confluence structurée par test avec contexte, résultats et points de vigilance, liée à la page centrale Meraki.
Centralisation du parc réseau
KB ServiceNow documentant l'architecture de la donnée, la logique de mapping et la procédure d'ajout de matériel.