Imaginons un lundi matin, à 8 h 40. Le tableau de bord commercial n’a pas été actualisé : le traitement de la nuit a échoué. La personne qui doit intervenir a le code et les accès, mais elle n’a pas construit le système. Avant la réunion de 10 h, elle doit trouver quelles données manquent, décider quoi relancer et vérifier que les chiffres sont justes.
Combien de temps lui faut-il ? Et combien de réponses n’existent que dans la tête de la personne qui a construit la plateforme ?
Pour moi, cette question fait partie de la qualité d’une livraison, au même titre que la justesse des chiffres. Une plateforme bien livrée permet à une personne qui maîtrise la stack de prendre en charge les opérations courantes sans dépendre en permanence de son concepteur. Elle aura un métier à découvrir et une architecture à apprendre. Retrouver une décision, identifier une dépendance ou relancer un traitement ne devrait pas l’obliger à fouiller d’anciens fils de discussion.
La reprise se joue dans l’architecture
Sur une stack BigQuery et dbt, lire le SQL donne les transformations. Pour exploiter le système, il faut aussi savoir comment les données arrivent, ce qui déclenche les traitements, quels accès sont nécessaires et comment les erreurs remontent.
J’applique donc les mêmes conventions partout. Si dix sources sont chargées selon le même principe, comprendre la première donne des repères pour les neuf autres. Une exception est parfois justifiée ; elle est alors nommée et expliquée à l’endroit où on la rencontre.
Pour les opérations courantes, je fais passer la cohérence de l’ensemble avant l’optimisation de chaque composant. Un connecteur sur mesure peut être plus performant pris isolément et coûter des heures à la personne qui l’exploite au milieu de tout le reste.
Même logique pour les outils. Chaque brique ajoutée est à comprendre, configurer, maintenir et payer. J’en ajoute une quand je peux dire quel besoin elle couvre et pourquoi l’existant n’y répond pas.
Et avant de documenter une architecture compliquée, je cherche à la simplifier.
Documenter ce que le code ne dit pas
Je ne paraphrase pas le SQL en français. Je documente ce que la lecture du code ne permet pas de retrouver avec certitude : les décisions et les limites.
Prenons un indicateur de commandes confirmées. Un filtre sur le statut est parfaitement lisible. Il ne dit pas si le modèle décrit l’état actuel de la commande ou un événement de son histoire, pourquoi on retient la confirmation plutôt que l’expédition, ni quelle équipe a fixé la règle. Sans ces réponses, la personne suivante ne sait pas si elle regarde une règle voulue ou un bug, ni à qui parler avant de la modifier.
Voici un exemple fictif de règle documentée :
Commande comptée : toute commande ayant connu une première confirmation, comptée à la date de cet événement à partir de l’historique des statuts.
Pourquoi : le marketing suit les commandes confirmées sans attendre leur expédition.
Conséquence : une annulation ultérieure ne retire pas la confirmation de cet indicateur. Les annulations et le revenu net sont suivis séparément.
Référente métier : direction marketing.
Les limites ont droit au même traitement. L’API d’une source ne renvoie qu’une partie de l’historique. Une période n’a jamais pu être récupérée. Un fichier doit encore être déposé à la main chaque mois. Je les regroupe à un seul endroit, chacune avec sa conséquence pratique, parce qu’une limite découverte en plein incident retarde le diagnostic et complique la reprise.
Transmettre de quoi agir
La personne qui reprend doit aussi pouvoir intervenir.
Une procédure intitulée « Relancer le traitement » ne sert que si elle dit quand relancer et ce que la relance va produire. Remplace-t-elle les données d’une période ? Complète-t-elle les trous ? Peut-elle créer des doublons ? Que faut-il vérifier ensuite ?
Exemple simplifié : recalculer une journée de commandes
Avant d’agir : vérifier que les données brutes de la journée sont complètes et qu’aucun traitement concurrent n’est en cours. Si elles sont incomplètes, rétablir d’abord le chargement depuis la source.
Effet prévu : dans cet exemple, le traitement remplace les données de la journée choisie ; une relance répétée ne les ajoute pas une seconde fois.
Mode opératoire : à préciser dans la fiche — commande ou workflow à lancer, paramètres attendus, environnement concerné.
Après l’exécution : vérifier les volumes attendus, l’unicité des commandes et la mise à jour du tableau de bord.
Arrêter et demander de l’aide : si les prérequis ne sont pas remplis ou si les contrôles restent en échec.
Les contrôles suivent la même exigence. Un traitement exécuté sans erreur ne garantit pas que les données attendues sont là. Je distingue les contrôles d’exécution des contrôles de contenu (volume, fraîcheur, unicité) et j’écris ce que chacun couvre.
Les accès font partie de la transmission. Qui administre le projet cloud ? Qui peut accorder une permission ? À qui appartient le compte de service qui se connecte à l’outil e-commerce ? Ces réponses doivent être écrites quelque part, pour que l’exploitation ne dépende pas de la disponibilité d’une seule personne.
Enfin, chaque lecteur a son niveau de détail. La personne qui dirige l’activité doit connaître les dépendances critiques et l’impact d’un incident. La personne qui intervient a besoin des procédures et des accès.
Avec un budget limité, je protège d’abord ce qui est critique
Tout cela prend du temps, et une petite équipe ne peut pas l’investir partout. Je répartis l’effort selon deux critères distincts : l’impact d’une erreur, et l’effort nécessaire pour rétablir la situation.
| Facile à reconstruire | Difficile à reconstituer | |
|---|---|---|
| Erreur peu coûteuse | une convention, une ligne | la source et ses limites décrites |
| Erreur coûteuse | contrôles et procédure de reprise courte | règle écrite, contrôles, procédure testée |
Les deux axes se lisent séparément. Une table intermédiaire reconstruite en dix minutes reste critique si elle alimente une décision budgétaire. Un historique peu consulté mérite une attention particulière s’il est impossible à récupérer.
Cet arbitrage figure dans le périmètre du projet. Si une première version demande une intervention manuelle, je précise laquelle, qui la réalise et ce qui reste à automatiser. Le client décide en connaissance de cause. Je livre volontiers un périmètre plus réduit dont le fonctionnement est maîtrisé.
La documentation elle-même suit ce principe. Chaque information importante a un emplacement unique, et je traite la mise à jour d’une explication comme une partie de la modification de la règle correspondante. Quelques pages entretenues valent mieux qu’un dossier exhaustif dont plus personne ne sait ce qui est encore vrai.
Déléguer sans être captif
Une PME peut choisir de confier durablement l’exploitation de sa plateforme à un prestataire plutôt que de constituer une équipe interne. Ce choix ne devrait pas réduire sa capacité à changer d’organisation plus tard.
La capacité de reprise compte justement dans ce cas. C’est elle qui permet au client de faire évoluer son organisation : recruter une première personne en interne, confier une partie du périmètre à un autre prestataire, commander un audit indépendant.
Je veux que mes clients continuent à travailler avec moi pour la qualité du travail et ma connaissance de leur métier, en sachant ce qu’ils délèguent et ce que demanderait un changement.
Toutes les dépendances ne disparaissent pas pour autant. Une plateforme repose sur des services, des bibliothèques, parfois des composants spécifiques, et en changer demande du travail. Les dépendances critiques sont identifiées, avec ce qu’impliquerait leur remplacement : ce qu’il faudrait migrer, réécrire ou reconfigurer.
Faire de la reprise un critère de recette
Pour moi, la capacité de reprise devrait faire partie de la recette. Une manière de la vérifier consiste à confier quelques opérations définies à une personne qui n’a pas construit le système. Elle doit pouvoir :
- retrouver la définition d’un indicateur ;
- identifier le traitement qui l’alimente ;
- vérifier sa fraîcheur ;
- suivre la procédure de relance sur un environnement de test ;
- faire une modification limitée et la déployer.
On observe où elle bloque. Une étape absente, un accès introuvable, une règle ambiguë deviennent des corrections précises. L’exercice se dimensionne selon le projet et complète les tests et la formation.
Le code, les modèles et les traitements font partie de la livraison. La capacité de l’équipe suivante à les comprendre, les exploiter et les faire évoluer aussi.