Airbay Data

Le contexte

L'entreprise édite des logiciels de gestion de la relation client sur mesure pour des sociétés du secteur de la rénovation énergétique. Elle n'exploite pas elle-même les dossiers de travaux : elle fabrique les outils qui permettent à ses clients de le faire, déployés et maintenus dans la durée. Plusieurs produits coexistent, partagent un socle technique commun, servent des métiers différents, et doivent se parler.

Chacun est une base de production vivante. Le CRM principal sur lequel j'ai travaillé est utilisé au quotidien par environ deux cents personnes, réparties sur six métiers aux besoins très différents. Toute opération sur ses données avait un effet direct et immédiat sur le travail de ces utilisateurs — il n'y avait pas d'environnement de répétition.

Pourquoi ce métier complique la base

Ces logiciels servent le montage de dossiers de travaux financés par le dispositif des Certificats d'Économie d'Énergie. Pour chaque opération — isoler des combles, installer une pompe à chaleur — il faut constituer un dossier conforme à une fiche standardisée, et chaque fiche définit ses propres critères techniques d'éligibilité et ses propres pièces justificatives.

Cette contrainte réglementaire descend directement dans le modèle de données, et c'est ce qui rend le sujet intéressant :

• Un état technique très détaillé. Type de chauffage, émetteurs, production d'eau chaude, parois, menuiseries, surfaces — tout cela conditionne l'éligibilité et doit donc être modélisé finement, pas résumé.
• Plusieurs fiches pour un même dossier. Un dossier peut relever de plusieurs fiches simultanément, ce qui interdit de réduire la fiche à un simple champ. Une évolution du modèle a consisté à la faire passer d'une valeur unique à une liste.
• Des calculs normés. Les volumes d'énergie économisée dépendent de paramètres réglementaires — zone climatique, situation du ménage — qui doivent être stockés et rester justes dans le temps.
• Une chaîne à cinq acteurs. Apporteur d'affaires, commercial, planificateur, inspecteur ou thermicien, administration : un même dossier passe entre leurs mains successives, et chacun ne doit voir que son périmètre.

Et la règle simple — « chacun ne voit que les dossiers de son agence » — ne suffit pas : un planificateur ou un inspecteur doit légitimement déborder ce cloisonnement. Cette tension entre cloisonnement par défaut et dérogations métier est exactement ce que la sécurité au niveau de la base a dû exprimer.

Ma place exacte

Je n'ai pas construit ces produits depuis une page blanche, et je préfère le dire clairement : le socle applicatif — interface, authentification, écrans de saisie, navigation — avait été conçu par un développeur de l'équipe avant mon arrivée, et le client validait les besoins métier.

J'ai été intégré comme référent du volet données et intégration. Le modèle, les migrations, l'intégration entre systèmes, la qualité, la sécurité, et surtout l'exécution en production, relevaient de ma responsabilité. J'ai travaillé en grande autonomie sur ce périmètre.

Trois principes de méthode

• Sur une base vivante, avancer par étapes. Jamais de migration de schéma sans sauvegarde préalable et sans stratégie en plusieurs temps : d'abord additive — ajouter sans casser l'existant — puis en double écriture, et seulement ensuite la suppression de l'ancien dispositif, une fois la cohabitation validée.
• Exécuter à la main, et le revendiquer. Les migrations étaient jouées une par une dans l'éditeur de la base de production, après relecture. Ce choix volontairement artisanal force la vigilance sur une base partagée — au prix d'une industrialisation incomplète que j'assume et que je critique plus bas.
• Tout doit être vérifiable. Une donnée migrée ou synchronisée n'a de valeur que si l'on peut prouver son intégrité. Chaque traitement était donc accompagné de comptages, de requêtes de cohérence, et de contrôles miroir bilatéraux lorsque deux systèmes devaient refléter la même réalité.

Ce que j'en retiens

Sur une base de production, la question n'est jamais « est-ce que mon script marche » mais « qu'est-ce qui se passe s'il s'arrête au milieu ». J'ai appris à écrire des opérations qu'on peut relancer sans dégât, à vérifier avant d'écrire plutôt qu'à réparer après, et à accepter qu'une donnée imparfaite entre quand même — à condition de la marquer comme telle.

Chaque incident m'a laissé un réflexe de diagnostic réutilisable : vérifier la donnée avant d'accuser le code, inspecter un enregistrement réel avant de conclure, suspecter l'effet de bord d'une opération structurelle. Cette capacité à isoler une cause sur un système complexe est ce que je retiens de plus précieux de ces trois mois.

Une limite, enfin, que je dois reconnaître. Appliquée manuellement, ma discipline de migration ne maintenait pas d'état fiable de ce qui était réellement passé en base. J'ai découvert sur certaines bases héritées des migrations partiellement appliquées — la structure passée, mais une contrainte oubliée — produisant des bugs qui ressemblaient à des erreurs de code alors qu'ils venaient du schéma. Un véritable gestionnaire de migrations versionné est la première amélioration à apporter.

Il manquait aussi une alerte automatique sur la cohérence des données : le suivi reposait sur des contrôles manuels après opération. La vigilance humaine restait indispensable, ce qui n'est pas une garantie qui passe à l'échelle.