Documentation interne.
On rédige avec vos équipes : runbook ops (incidents, on-call, déploiement), ADRs (Architecture Decision Records), guide d’onboarding dev (J1 → S4), cartographie de la stack. Ce que vous reportez depuis 2 ans, on le pose en 2 à 4 semaines — pas une consultance qui sort un livrable jamais lu, des ateliers où vos devs co-rédigent et adoptent le résultat.
Cette offre vous parle si…
- Vous êtes CTO et vous savez que la doc traîne — mais aucun dev ne veut la rédiger seul, et personne n’a le temps de coordonner.
- Vous embauchez 3 à 8 devs dans les 6 mois et vous voulez un onboarding qui tienne en 4 semaines, pas en 6 mois.
- Vous avez survécu à un incident douloureux et vous voulez un runbook avant le prochain.
- Vous préparez une levée ou une revente — la due diligence va vous demander des ADRs et vous n’en avez pas.
- Votre équipe a fait des choix d’archi tordus dont personne ne se souvient des raisons — et qu’on remet en question chaque trimestre.
- Votre on-call est de l’improvisation totale et vous voulez que le dev de garde sache exactement quoi faire à 3h du matin.
La doc interne, c’est ce qu’on reporte 18 mois avant d’en payer le prix
Tout le monde sait qu’il faut documenter. Personne ne le fait. La raison n’est pas la flemme — c’est l’absence de cadre et de méthode. Un dev seul ne sait pas quoi rédiger en premier, dans quel format, à qui ça sert. Résultat : trois fichiers README incomplets dans un coin du repo et un Notion abandonné. Une mission documentation marche parce qu’elle apporte le cadre, la méthode, et un partenaire qui co-rédige avec l’équipe — pas un consultant qui livre un pdf jamais lu.
- Onboarding qui prend 6 mois au lieu de 4 semaines — perte sèche par dev
- Incident à 3h du matin : dev de garde livré à lui-même → impact client max
- Décisions d’archi remises en question chaque trimestre faute de trace
- Audit due diligence levée de fonds : pas d’ADR, pas de bonus de valorisation
- Bus factor 1 : si Untel part, l’équipe perd 40 % de la connaissance
Scope concret, sans flou
- Livrable 101
Runbook ops — incidents, on-call, déploiement
Le document qui sauve la nuit du dev de garde. On formalise les procédures incident (qui prévenir, comment escalader, quoi vérifier en premier), les routines de déploiement (checklist pré-déploy, rollback, post-mortem), et les rotations on-call.
- Procédure incident sévère : qui décide, qui exécute, qui communique
- Checklist déploiement (pré, pendant, post)
- Template post-mortem blameless avec exemples passés réécrits
- Calendrier on-call + escalade + back-up
- Livrable 202
ADRs — Architecture Decision Records
On capture les 10-20 décisions d’archi structurantes prises dans les 3 dernières années. Format ADR (contexte, options envisagées, décision, conséquences). Ça évite à votre équipe de remettre en question chaque trimestre une décision déjà prise et oubliée, et ça rassure tous les futurs CTO ou auditeurs.
- Template ADR adapté à votre équipe (markdown dans le repo)
- Top 10-20 décisions historiques rétro-documentées
- Process : comment proposer / valider une nouvelle ADR
- Index ADR dans le repo, ADR-NNN-titre.md, ordre chronologique
- Livrable 303
Guide onboarding dev — J1 → S4
Le guide qu’on aurait voulu avoir le jour de son arrivée. Setup machine en 1h, tour de la stack en 1 jour, ramp-up dev en 4 semaines avec missions précises. À la fin de la semaine 4, le dev embauché push en prod sereinement. Ça transforme votre taux d’attrition les 6 premiers mois.
- J1 : setup machine, accès, tour des outils (1 demi-journée)
- S1 : tour de la stack avec lead tech (binôme), première PR simple
- S2-3 : sujets ramp-up avec mentor, code review intensive
- S4 : autonome sur un périmètre, première astreinte ombrée
- Livrable 404
Cartographie de la stack — services, deps, contrats
Une carte vivante de votre système : services (qui parle à qui), dépendances externes (qui paye quoi, qui plante quand), contrats d’API (entrées / sorties par endpoint). Mise à jour automatisée quand c’est possible, manuelle sinon mais cadencée.
- Diagramme système C4 (Context, Container, Component) — Excalidraw
- Inventaire dépendances externes : SLA, coût, plan de migration si dispo
- Schémas contrats API les plus critiques (OpenAPI ou markdown)
- Process de mise à jour : qui touche quoi quand on modifie
- Méthode05
Ateliers co-rédigés, pas un livrable mort
On bosse par ateliers de 90 min avec vos devs, 2 à 3 fois par semaine. Vous rédigez avec moi, vous validez en live, vous adoptez immédiatement. Ce qui rend ces docs vivantes après mon départ — pas un pdf jamais lu, mais un wiki que l’équipe enrichit parce qu’elle l’a co-construit.
- Atelier 90 min, 2-3 fois par semaine, avec un dev référent à chaque fois
- Rédaction live, validation en séance, push dans le repo immédiatement
- Hand-over à un dev référent qui devient l’owner du doc
- Process de mise à jour cadencé : qui revoit quoi à quelle fréquence
Le scope complet, sans surprise sur la facture
- Audit doc existante J1 (1h) — état des lieux honnête
- Templates Markdown prêts à copier (runbook, ADR, onboarding, carto)
- Tous les docs poussés dans votre repo (pas Notion, pas Confluence — repo)
- Pull requests dédiées par livrable, revues avec votre équipe
- Diagrammes Excalidraw exportés (SVG + json éditable)
- Process de mise à jour documenté (qui, quoi, quand)
- Hand-over formel à un dev référent (1h par livrable)
- Replay des ateliers (mp4, accès interne illimité)
- Accès Slack privé 60 jours après fin de mission
- Debrief 1h à J+60 — état d’adoption des docs
- Attestation Qualiopi en cours, OPCO bientôt activable
- Pas de pdf jeté en livrable, tout est dans votre repo
Prix posé, sans devis à rallonge
Mission 2 à 4 semaines selon scope. 4 800 € pour 1 livrable seul (ex : juste le runbook). 7 200 € pour 2 livrables. 9 600 € pour 3 livrables. 12 000 € pour les 4 livrables complets. Audit doc existante (1h) offert pour cadrer le périmètre exact.
- En présentiel ou visio
- Ateliers de 90 min
- Qualiopi en cours
- OPCO bientôt possible
On vous a vu venir
Combien de devs doivent participer aux ateliers ?
Idéalement 2 à 4 personnes par livrable, dont au moins 1 dev senior référent qui sera owner du doc après. Pas besoin que toute l’équipe participe à tous les ateliers — on choisit le ou les devs les mieux placés selon le sujet (le SRE pour le runbook, le tech lead pour les ADRs, le dev récemment embauché pour l’onboarding).
Présentiel ou visio ?
Les deux marchent. Visio par défaut sur Meet ou Zoom avec partage d’écran permanent (et Excalidraw partagé pour les schémas). Présentiel possible sur Paris / IDF sans surcoût. Pour les ateliers de cartographie système, le présentiel marche un peu mieux — on a besoin d’un grand tableau ou d’un mur de post-it parfois.
Pourquoi pas Notion ou Confluence ?
Parce que la doc qui survit, c’est celle qui est versionnée à côté du code, revue en PR, et qui plante la CI quand elle est obsolète. Notion et Confluence finissent en cimetière. Markdown dans le repo, c’est austère, mais c’est ça qui dure 5 ans. Si vous tenez à Notion / Confluence pour des raisons non-techniques (comm, équipe non-dev), on peut publier les docs ailleurs en plus du repo.
Le replay des ateliers est dispo combien de temps ?
À vie. Liens Vimeo privés envoyés sous 72h après chaque atelier. Vous pouvez les repartager dans l’équipe à des collègues qui n’ont pas participé.
Et après la mission, qui maintient les docs ?
C’est le sens du hand-over formel à un dev référent (owner par livrable). On documente aussi le process de mise à jour : qui revoit quoi, à quelle fréquence. Ça ne marche que si quelqu’un dans l’équipe en hérite vraiment — pas si ça reste "la doc de Opcodia". Si vous voulez de l’accompagnement de moyen terme, on peut convertir en coaching 1-1 (240 €/h) pour le dev référent.
Trois semaines, et la doc devient un actif vivant.
Audit gratuit 1h en visio pour évaluer votre doc existante et cadrer le périmètre. Si on se rend compte qu’une mission complète n’est pas le bon format (par ex. il vous faut juste 2 ADRs urgents), on bascule sur du coaching à l’heure.
Réserver l’audit doc gratuit