Compétence technique
Documentation technique
Garantir la transmission du savoir et la pérennité du système d'information.
L'essentiel
La documentation technique transforme une intervention ponctuelle en capital collectif : sans elle, si l'ingénieur qui a conçu le système n'est plus disponible, la connaissance disparaît avec lui. Dans un environnement comme Criteo, où les projets s'enchaînent et les équipes évoluent, ce n'est pas une tâche annexe, c'est un livrable à part entière. Un DAT bien rédigé vaut autant qu'une configuration bien 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é.
En pratique
Extension réseau →
Pour l'Innovation Hub, un DAT complet couvrant topologie, décisions d'architecture, VLANs, flux d'authentification et conditions de rollback, avec schémas Lucidchart. Il sert aujourd'hui de référence pour les futurs déploiements d'étages chez Criteo.
Lab staging →
Documentation du Lab structurée dans Confluence, une page par test avec contexte, résultats et points de vigilance, liée à la page principale Meraki, pour que n'importe qui puisse l'utiliser sans dépendre de ma disponibilité.
Centralisation parc →
Article de Knowledge Base sur l'utilisation de ServiceNow et la procédure d'ajout de matériel, plus des pages de suivi qui transforment chaque incident significatif en capital partagé.
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é.
Où j'en suis, où je vais
Ma limite principale : mes documents sont détaillés sur le « quoi » et le « comment », moins sur le « pourquoi » des choix d'architecture, souvent le plus utile pour qui reprend le projet. J'ai mis en place une règle contre la dette documentaire (aucun ticket fermé sans KB à jour si l'incident a révélé quelque chose de nouveau), et je m'intéresse à la documentation « as code » (Markdown, Git) pour la versionner comme le code et détecter les dérives entre doc et réalité du système.
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.
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.