Pour Camtek, l'histoire du DWH a commencé il y a bientôt 20 ans, avec la demande d'un client pour le développement d'une interface de transmission de fichiers pour le SAE. La question s'est alors posée de créer un entrepôt de données à façon. L'interface entre des solutions logicielles implique de mettre en place un modèle communiquant selon les spécifications du fabricant/éditeur. En effet, des subtilités peuvent avoir de l'importance (par exemple, certains parlent de "voiture", d'autres préfèrent "service matériel"). À cela s'ajoutent aussi des périmètres d'actions différents. L'idée est de créer un format pivot pour l'ensemble des données : avec une structuration en entrée et les paramétrages nécessaires pour les flux en sortie. En prenant toutes les données relatives à l'offre de transport, le DWH devient ainsi la base de données structurées et disponibles pour communiquer avec tous les dispositifs installés.

 

En 2000 (les premières solutions logicielles pour le transport public datent du milieu des années 1990), Camtek choisit de partir d'un modèle de données de référence pour le transport public (Transmodel), pour parler Transport et non Informatique (nous pouvons dire qu'il s'agissait d'une orientation UX). Avec ce fond documentaire commun avec ses clients, Camtek privilégie une base de données relationnelle, open source, avec un modèle standardisé des données en entrée pour une diffusion en aval.

 

Les sources en entrée et en sortie sont multiples, diverses et évolutives. Des plugins sont développés pour le chargement des données des dispositifs montants, avec une structuration dans un format pivot. Et, pour tenir compte de la variété des sources (Hastus, Okapi, HubVeolia, Excel...), des plugins dédiés assurent un upload dans le modèle standard du DWH. Une mise à jour, une évolution ou encore un changement de la source (par exemple, passage de Hastus à Okapi) nécessiteront juste une mise à jour du plugin, et donc un temps court de développement, en tenant compte des règles d'applications, des comportements et des spécificités propres au système du client utilisateur. Ainsi, pour le plugin billettique, Camtek a identifié 8 comportements différents, avec une mise à jour nécessaire chaque trimestre (en moyenne). La compatibilité ascendante est déterminante. En effet, chaque nouvelle version Excel impose de reformater toutes les macros, idem pour les solutions logicielles leader pour le transport public.

 

Les plugins de sortie ont pour mission de créer des fichiers de données pour alimenter les dispositifs, selon les modalités de dialogue et l'environnement. Des mises à jour sont développées, pour les mêmes motifs que pour les plugins ascendants. Ainsi, quand le DWH est implémenté, l'ensemble des données de l'offre de transport est intégré chez le client, la donnée est structurée, qualifiée multi sources et disponible pour tous les dispositifs. Le client connait et maîtrise alors ses données : qualité, cohérence, accessibilité et disponibilité (fin des ressaisies). La sécurité est assurée : le DWH s'appuie sur une architecture client-serveur, avec une base de données ressources appelée par une chain commande sous Windows. L'environnement Windows est privilégié (là encore, une approche UX) pour convenir aux standards des acteurs du secteur Transport.

 

Un autre avantage de la donnée disponible et structurée dans le DWH est la visualisation. Les données sont directement opérationnelles notamment pour les traitements nécessaires au Service Marketing (comme les grilles horaires, les fiches aux poteaux…), ou encore pour l'Exploitation avec les feuilles de services, la génération des indicateurs de l’activité et le reporting. Le DWH apparaît donc comme une solution éprouvée, avec d'importants gains de productivité. Performance + Qualité + Agilité = DWH.