L'entrepôt de données foncières

Le besoin

Cet outil est un véritable petit entrepôt de données foncières. Il enrichit des prospects à partir de sept sources publiques — registres d'entreprises, cadastre, base nationale des bâtiments, données de valeurs foncières — pour estimer un potentiel de travaux. Il se situe tout en amont du tunnel : il qualifie des prospects avant de les pousser vers le CRM commercial.

C'est un cas d'école de modélisation de données externes hétérogènes : sept sources, sept formats, sept fréquences de mise à jour, et une seule question à laquelle répondre — ce bien vaut-il un appel.

L'audit de sécurité

Ma contribution principale a été un audit de sécurité des données. J'ai analysé le modèle et constaté deux problèmes de fond.

• Des politiques de sécurité non versionnées. Les règles d'accès existaient dans la base mais pas dans le dépôt de code. Personne ne pouvait donc dire quand une règle avait changé, ni pourquoi, ni la restaurer après une migration malheureuse — c'est précisément le scénario qui a causé la fuite d'isolation sur le projet phare.
• Une table de prospects sans propriétaire. La table ne portait aucun identifiant de propriétaire, ce qui rendait tout cloisonnement impossible à écrire : un risque de fuite de données personnelles entre utilisateurs.

J'ai produit une matrice de recommandations pour y remédier. Ce travail d'audit a eu un effet secondaire précieux : il m'a servi de source de bonnes pratiques, que j'ai ensuite réutilisées sur le CRM d'audit — et c'est en partie ce qui m'a permis de reconnaître la fuite d'isolation quand elle est survenue.

Les produits de l'entreprise partagent le même socle technique, ce qui fait gagner du temps d'un projet à l'autre. Le revers est direct : une faiblesse copiée d'un produit se retrouve dans les suivants. C'est pour cette raison que la matrice de recommandations a servi au-delà de cet outil.