Petit détaillant
Architecture en couches
FootfallCam V9 L'architecture est structurée en couches afin de permettre aux aéroports d'adopter, d'exploiter et d'étendre leurs capacités d'intégration sans s'engager sur une voie unique. Chaque couche présente des entrées et des sorties clairement définies et peut être utilisée indépendamment ou en combinaison avec d'autres. Les aéroports peuvent ainsi commencer par un accès simple aux données et la génération de rapports, et approfondir l'intégration uniquement lorsque cela s'avère nécessaire.
Interfaces d'intégration
FootfallCam V9 Il prend en charge de multiples interfaces d'intégration qui relient l'architecture en couches aux systèmes aéroportuaires existants. Ces interfaces illustrent comment les données opérationnelles peuvent être échangées sans remplacer ni empiéter sur les plateformes existantes.
Voici quelques exemples d'intégration courants :
Interfaces de référence AODB / FIDS
- Référence de vol
- Référence de la porte et du stand
- Fenêtres ETA/ETD
- groupement de vols
Flux opérationnels APOC
- États de congestion
- Indicateurs de franchissement de seuil
- Pression opérationnelle prévue
- Notifications d'alerte
Il s'agit d'exemples représentatifs et non d'une liste exhaustive. La même architecture prend en charge d'autres interfaces, notamment les plateformes de BI, les systèmes de reporting et les outils opérationnels tiers.
Surveillance de la santé
La surveillance de la santé couvre le fonctionnement de l'intégration elle-même.
Il permet de vérifier si les pipelines de données, les interfaces et la distribution des alertes fonctionnent comme prévu, sur toutes les couches d'intégration activées.
La surveillance couvre :
- disponibilité du pipeline de données
- connectivité de l'interface
- État de la distribution des événements et des alertes
- Indicateurs SLA et de service
La surveillance de l'état de santé facilite le fonctionnement courant, le diagnostic des pannes et l'audit, sans affecter les systèmes aéroportuaires en amont.
Étude de Cas
Voici quelques-uns de nos déploiements dans différents aéroports
Diligence raisonnable pour l'expansion du terminal
Examen d'intégration axé sur l'audit
Surveillance de la santé et visibilité des SLA
Corrélation AODB/FIDS
Activation progressive des APOC
Congestion des bagages
Preuves de file d'attente au contrôle frontalier
Signalement - Premier aéroport régional
Évaluation du rendement des entrepreneurs
Optimisation des points de contrôle de sécurité
Diligence raisonnable pour l'expansion du terminal
Étude de cas 1
Vérification préalable multipartite avant l'agrandissement du terminal
Situation
Le projet d'agrandissement du terminal nécessitait l'approbation de multiples parties prenantes, notamment les compagnies aériennes, les autorités de réglementation et les investisseurs. Chacune d'elles a remis en question les hypothèses relatives au flux de passagers et à la congestion futurs. L'aéroport avait besoin de données pour étayer son dossier sans s'engager dans une intégration analytique à long terme avant l'approbation du financement.
Mise en œuvre
FootfallCam Une couche analytique temporaire a été déployée pour recueillir les scénarios de flux de référence et prévisionnels. Les données étaient accessibles uniquement via des tableaux de bord et des exportations. Le périmètre d'intégration et la durée de conservation des données étaient clairement définis. Un système de surveillance de l'état du système a été activé afin de garantir l'exhaustivité des données pour les audits.
Résultat
L'aéroport a fourni des preuves crédibles à l'appui de ses hypothèses d'expansion. Les parties prenantes ont accepté les conclusions car le déploiement de l'analyse était circonscrit, transparent et réversible. Une fois les approbations obtenues, l'aéroport a conservé la possibilité d'étendre ou de supprimer la couche d'analyse sans avoir à la remanier.
Examen d'intégration axé sur l'audit
Étude de cas 2
Examen d'intégration axé sur l'audit pour un aéroport du secteur public
Situation
Un aéroport public a fait l'objet d'audits réguliers portant sur la gouvernance des données, la dépendance vis-à-vis des fournisseurs et la responsabilité opérationnelle. Les intégrations précédentes avaient échoué aux audits en raison d'une imprécision dans la définition de la propriété des données et d'un manque de suivi. Toute nouvelle intégration exigeait des contrôles et des options de sortie clairement définis.
Mise en œuvre
FootfallCam L'intégration a été documentée à l'aide d'un modèle d'architecture en couches, avec des limites et une surveillance clairement définies. Des contrôles d'intégrité, des journaux de livraison et des indicateurs de SLA ont été mis en place pour étayer les preuves d'audit. Les exportations de données et les API ont été documentées dans le cadre du dossier d'approvisionnement.
Résultat
L'aéroport a passé avec succès l'audit sans qu'aucune mesure corrective relative à l'intégration des données analytiques ne soit requise. Les équipes de gouvernance ont validé le déploiement, le jugeant circonscrit et observable. L'aéroport a conservé la possibilité d'étendre ou de réduire le périmètre d'intégration sans renégociation contractuelle ni architecturale.
Surveillance de la santé et visibilité des SLA
Étude de cas 3
« Une intégration que vous pouvez exploiter » : Surveillance de l’état et visibilité des SLA
Situation
Un grand aéroport avait connu des défaillances d'intégration avec ses précédents fournisseurs : interruptions silencieuses, flux de données manquants et imprécision dans la définition des responsabilités. L'impact opérationnel ne résidait pas toujours dans la panne elle-même, mais dans le temps perdu à identifier l'origine du problème (appareil, réseau, API, système en aval ou modification de configuration). L'exigence de diligence raisonnable de l'aéroport était simple : toute intégration devait être observable et auditable.
Mise en œuvre
La surveillance de l'état de santé était intégrée au processus, et non considérée comme une option supplémentaire. Elle couvrait la disponibilité du pipeline, la connectivité des interfaces, l'état de la distribution des événements et les indicateurs de SLA. Les journaux de distribution et les indicateurs d'exhaustivité étaient mis à disposition pour faciliter le tri des incidents. L'aéroport a défini les procédures d'escalade et les exigences en matière de preuves pour les incidents d'intégration (éléments à vérifier en priorité, éléments à exporter pour audit).
Résultat
Les problèmes d'intégration sont devenus diagnostiques plutôt que politiques. En cas de dégradation d'un flux de données, l'aéroport pouvait isoler la couche affectée et prendre des mesures correctives sans perturber les systèmes en amont. Les équipes d'approvisionnement et de gouvernance ont plus facilement accepté l'intégration grâce à une supervision opérationnelle intégrée dès la conception, conforme aux procédures d'exploitation auditables.
Corrélation AODB/FIDS
Étude de cas 4
Corrélation AODB/FIDS pour l'analyse des trajectoires de vol (points d'accès en lecture seule)
Situation
Un hub de taille moyenne a connu de fortes congestions dues aux perturbations de vols. Les opérations constataient ces congestions, mais ne pouvaient les imputer avec certitude aux modifications d'horaires, aux changements de postes de stationnement ou aux réaffectations de portes d'embarquement sans vérifications croisées manuelles. L'aéroport disposait d'une base de données aéroportuaires (AODB) et d'un système d'affichage des informations de vol (FIDS), mais les initiatives analytiques visant à centraliser toutes les données ont été rejetées car elles brouillaient les responsabilités et engendraient des tensions entre les équipes.
Mise en œuvre
L'aéroport a activé des points de corrélation en lecture seule : référence de vol, référence de porte/stationnement, fenêtres ETA/ETD et fenêtres de banc de vols. FootfallCam Les données de sortie sont restées basées sur les événements et les agrégats ; AODB est restée la référence en matière de données de vol. Des champs corrélés ont été ajoutés à des fins d’analyse et de reporting, mais n’ont pas été utilisés pour le pilotage opérationnel. L’intégration a été mise en œuvre via une interface délimitée, avec un mappage défini et un processus de modification contrôlé.
Résultat
L'aéroport a ainsi pu obtenir un système de reporting fiable sur les flux de vols et la congestion sans avoir à réécrire les systèmes existants. Les équipes de planification ont pu identifier les flux de vols à l'origine de points de congestion récurrents et évaluer les politiques d'attribution des portes d'embarquement et des postes de stationnement à partir des mêmes données. Le service informatique a accepté cette approche car elle était en lecture seule, circonscrite et réversible.
Activation progressive des APOC
Étude de cas 5
Activation progressive des APOC dans un aéroport aux ressources limitées
Situation
Un aéroport souhaitait mettre en place un centre de commandement des opérations aéroportuaires (APOC), mais ne disposait pas des ressources nécessaires pour déployer un modèle opérationnel pleinement intégré. La direction recherchait des résultats rapides sans s'engager dans un vaste programme de transformation. Le risque était de déployer des outils qui seraient par la suite abandonnés ou nécessiteraient une refonte.
Mise en œuvre
L'aéroport a commencé par mettre en place des tableaux de bord et des règles pour définir en interne les niveaux de congestion. Les flux APOC n'ont été activés que pour un nombre restreint de zones, sous forme de signaux structurés. La surveillance de l'état du trafic a été activée dès le départ afin de garantir la fiabilité des flux. Les autres zones ont continué à utiliser des systèmes de reporting autonomes.
Résultat
L'aéroport a atteint une capacité APOC partielle, conforme à son niveau de maturité et à son budget. Les décisions d'expansion ont été prises progressivement, en se basant sur des données opérationnelles plutôt que sur de simples aspirations. Grâce à son architecture modulaire, aucune reconfiguration n'a été nécessaire malgré l'élargissement du périmètre.
Congestion des bagages
Étude de cas 6
Congestion au niveau de la zone de récupération des bagages sans contact avec le BHS
Situation
Un aéroport a connu des problèmes récurrents de congestion dans les halls de récupération des bagages aux heures de pointe. Bien que le système de traitement des bagages (STB) fournisse des informations sur l'état des tapis roulants et des alarmes, il n'offrait aucune visibilité sur la densité des passagers ni sur leur temps d'attente. Les propositions précédentes visant à intégrer directement des données analytiques aux flux de travail du STB ont été rejetées en raison des risques liés à la certification et des contraintes imposées par le fournisseur.
Mise en œuvre
FootfallCam Un système a été déployé dans les halls de reprise pour fournir des données de densité, de temps de séjour et d'état de congestion par zone. L'intégration s'est limitée aux tableaux de bord et aux exportations planifiées. Aucune intégration avec les systèmes de tri des conteneurs (BHS) n'a été tentée. Les zones opérationnelles ont été alignées sur les convoyeurs de reprise et les zones de circulation afin de garantir leur pertinence sans couplage du système.
Résultat
Les équipes d'exploitation ont bénéficié d'une visibilité accrue sur la congestion des zones de reprise, indépendamment des performances du système de triage. Les décisions relatives au personnel, à l'affectation des convoyeurs et à l'acheminement des passagers ont été étayées par des données objectives. L'approbation de la gouvernance a été obtenue car aucun système certifié n'a été modifié et les analyses sont restées observationnelles.
Amélioration des données relatives aux files d'attente aux contrôles frontaliers des passagers
Étude de cas 7
Les files d'attente au contrôle frontalier : éléments de preuve pour les négociations sur les effectifs
Situation
Les files d'attente aux contrôles frontaliers constituaient une source de tensions récurrentes entre l'aéroport, les agences gouvernementales et les compagnies aériennes. Chaque partie s'appuyait sur des données différentes, souvent issues d'échantillonnages manuels ou de témoignages anecdotiques. L'aéroport avait besoin de données cohérentes et fiables pour étayer les discussions relatives aux effectifs et à l'aménagement des zones, sans perturber le système de contrôle frontalier.
Mise en œuvre
FootfallCam Des outils d'analyse ont été déployés en amont et en aval des zones de contrôle frontalier. L'accès aux données était limité aux tableaux de bord et aux exportations, conformément aux périodes de reporting convenues. Aucun système d'alerte en temps réel ni flux de données externes n'était activé. Les définitions des files d'attente et des temps d'attente ont été convenues au préalable et documentées.
Résultat
L'aéroport a établi un ensemble de données neutres, accepté par toutes les parties prenantes. Les discussions ont alors porté non plus sur la contestation des chiffres, mais sur l'évaluation de différents scénarios d'effectifs. Le déploiement, limité et empirique, a permis d'éviter toute escalade réglementaire et a été accepté comme élément de preuve à l'appui plutôt que comme moyen de contrôle opérationnel.
Signalement - Premier aéroport régional
Étude de cas 8
« Déclaration en premier » pour un aéroport régional (exportation BI uniquement)
Situation
Un aéroport régional disposait d'équipes opérationnelles performantes, mais d'un service informatique restreint. Les évaluations de performance reposaient sur des dossiers de preuves manuels : captures d'écran, contrôles ponctuels et feuilles de calcul compilées par différents services. Les discussions sur la gestion des files d'attente étaient systématiquement bloquées par un problème : des plages horaires incohérentes, des heures manquantes et des désaccords sur les définitions (qu'est-ce qui constitue une « file d'attente », quand commence et quand se termine une attente). L'aéroport souhaitait disposer de jeux de données exploitables pour sa planification annuelle et la justification de son budget, sans pour autant lancer un nouveau projet d'intégration.
Mise en œuvre
FootfallCam Le système a été déployé uniquement comme source de rapports. La version 9 générait des agrégats horaires et journaliers par zone et exportait un jeu de données standard vers l'espace de travail décisionnel existant de l'aéroport. Les indicateurs clés de performance (KPI) propres à l'aéroport (files d'attente, créneaux horaires de pointe, cumuls par terminal) étaient configurés comme des métriques nommées afin de garantir la stabilité des rapports d'un mois à l'autre. Aucune corrélation AODB ni aucun flux APOC n'étaient activés à ce stade.
Résultat
L'aéroport a standardisé ses rapports sans toucher à ses systèmes centraux. Les revues opérationnelles sont passées d'une analyse de la fiabilité des chiffres à une planification des actions pour le trimestre suivant. L'équipe BI a ainsi obtenu des ensembles de données reproductibles, et l'aéroport a évité une crise de gouvernance grâce à une intégration limitée aux exportations. Le suivi a été activé uniquement pour vérifier l'état de livraison des exportations et l'exhaustivité des données.
Évaluation du rendement des entrepreneurs
Étude de cas 9
Évaluation des performances des entrepreneurs à l'aide de données indépendantes
Situation
Un aéroport a externalisé plusieurs fonctions opérationnelles, notamment le nettoyage et la gestion des files d'attente. Les évaluations de performance ont suscité la controverse en raison du manque de données objectives et cohérentes. Les systèmes des prestataires existants n'étaient pas alignés sur les indicateurs clés de performance de l'aéroport, et leur intégration n'a pas été jugée viable.
Mise en œuvre
FootfallCam Des outils d'analyse ont permis de mesurer indépendamment la congestion, le temps d'attente et l'utilisation dans les zones contractuelles. Les données ont été partagées par le biais d'exportations lors des cycles d'examen. Aucune intégration directe avec le système ni alerte en temps réel n'ont été activées. Les indicateurs ont été documentés et figés pour les périodes de reporting contractuelles.
Résultat
Les évaluations de performance sont devenues factuelles et moins conflictuelles. Les prestataires ont accepté les données comme neutres car elles n'étaient pas liées à leurs propres systèmes. L'aéroport a renforcé sa gouvernance sans accroître la complexité de l'intégration ni la dépendance opérationnelle.
Optimisation des points de contrôle de sécurité
Étude de cas 10
Optimisation des points de contrôle de sécurité sans remplacement du système
Situation
Un aéroport était confronté à des plaintes récurrentes concernant les temps d'attente aux contrôles de sécurité, notamment lors des pics saisonniers. Plusieurs systèmes étaient déjà en place : plannings du personnel, outils de gestion des files d'attente et procédures de signalement manuelles. Les propositions précédentes d'intégration poussée avec les systèmes de sécurité avaient été rejetées en raison de contraintes réglementaires et d'un manque de clarté quant aux responsabilités. L'aéroport avait besoin de données plus fiables pour ses décisions relatives au personnel et à l'aménagement des zones, sans pour autant modifier les plateformes de sécurité certifiées.
Mise en œuvre
FootfallCam Un système a été déployé en amont des points de contrôle de sécurité afin de fournir des données agrégées sur le flux, la longueur des files d'attente et les temps d'attente par zone. Ces données étaient utilisées exclusivement via des tableaux de bord et des exportations programmées. Aucune intégration directe avec les systèmes de sécurité n'a été mise en œuvre. Les indicateurs ont été alignés sur les périodes de reporting et la terminologie existantes de l'aéroport afin d'éviter de redéfinir le langage opérationnel.
Résultat
L'aéroport a ainsi obtenu des données probantes cohérentes et actualisées pour ses décisions relatives aux effectifs et à la configuration des voies. Les échanges avec les autorités de réglementation et les prestataires sont passés de retours d'information anecdotiques à des données structurées. Le périmètre d'intégration est resté limité et l'approbation des instances dirigeantes a été obtenue, aucun système certifié n'ayant été modifié ni couplé.