AO Mise en Place SOAM

Règlement de Consultation 207/18/AOO
ROYAUME DU MAROC
OFFICE NATIONAL DES AEROPORTS
DOSSIER D’APPEL D’OFFRES
Appel d’offres ouvert N° 207/18/AOO
Fourniture, installation, mise en service et maintenance d’un

Système des Opérations Aéroportuaires Multiplateformes
(SOAM)
 Tranche ferme : Fourniture, installation, mise en service et

maintenance d’un Système des Opérations Aéroportuaires
Multiplateformes (SOAM)
 Tranche conditionnelle : Maintenance du SOAM et
Assistance
ANNEXE IV : MODELE BORDEREAU DES PRIX – DETAIL ESTIMATIF (BDP-DE)- Tranche ferme-
Fourniture, installation, mise en service et maintenance d’un Système des Opérations Aéroportuaires Multiplateformes (SOAM)
Tranche ferme : Fourniture, installation et mise en service d’un Système des Opérations Aéroportuaires Multiplateformes (SOAM)
Ligne Description UDM Quantité PU Hors TVA EN PT Hors TVA EN
CHIFFRES CHIFFRES
1 Fourniture de la Partie matérielle de la plateforme Ensemble 1

redondante (Serveurs pour SOAM, équipements
réseau, Firewall, Antivirus…) pour la phase 1 : site
principal et site de backup à l’aéroport de
Casablanca
2 Fourniture de la Partie logicielle du SOAM (AODB, Ensemble 1

RMS, ESB, Base de données, système d'exploitation,
...) avec licence et support pour la phase 1 : les
aéroports de Casablanca, Rabat et Marrakech

RMS, ESB, Base de données, système d'exploitation,
...) avec licence et support pour la phase 2 : les
aéroports d’Agadir, Tanger, Fès, Oujda et Nador

ESB, Base de données, système d'exploitation, ...)
avec licence et support pour (la phase 3 : les
aéroports secondaires) à installer au site central à
Casablanca
5 Fourniture de la Partie matérielle (postes Opérateurs Ensemble 1

et postes de service) pour la phase 1: les aéroports
de Casablanca, Marrakech et Rabat

et postes de service) pour la phase 2 : les aéroports
d’Agadir, Tanger, Fès, Oujda et Nador

et postes de service) pour la phase 3 : les 11
aéroports secondaires
8 Conception, paramétrage, interfaçage, intégration Forfait 1

et Prestations d'installation, Test et mise en service de
la solution de la phase 1 (Casablanca, Rabat et
Marrakech)
9 Conception, paramétrage, interfaçage et Forfait 1

intégration et Prestations d'installation, Test et mise
en service de la solution de la phase 2 (Agadir,
Tanger, Fès, Oujda et Nador)
10 Conception, paramétrage, interfaçage et Forfait 1

intégration et Prestations d'installation, Test et mise
en service de la solution de la phase 3 (les aéroports
secondaires)
TOTAL HORS TVA Y COMPRIS DROITS DE DOUANES (A)
DONT MONTANT DROITS DE DOUANE
TVA 20% (B)
TOTAL TVA COMPRISE (A+B)

Cahier des prescriptions spéciales 207/18/AOO
Règlement de Consultation
207/18/AOO
Fourniture, installation, mise en service et maintenance d’un Système des Opérations 7/66 Aéroportuaires
ROYAUME DU MAROC
OFFICE NATIONAL DES AEROPORTS
CAHIER DES PRESCRIPTIONS SPECIALES
Appel d’offres ouvert N° 207/18/AOO
Fourniture, installation, mise en service et maintenance

d’un Système des Opérations Aéroportuaires
 Tranche ferme : Fourniture, installation et mise en service d’un

Système des Opérations Aéroportuaires Multiplateformes (SOAM)
 Tranche conditionnelle : Maintenance du SOAM et
Assistance
Table des matières
CHAPITRE 2 : CLAUSES TECHNIQUES – Tranche ferme -

Fourniture, installation, mise en service et maintenance d’un Système des Opérations
Aéroportuaires Multiplateformes (SOAM)
Tranche ferme : Fourniture, installation, mise en service et maintenance d’un Système des
Opérations Aéroportuaires Multiplateformes (SOAM)
ARTICLE 06 : DELAI D’EXECUTION
Le délai global d’exécution de la présente tranche ferme du marché est de dix-huit (18)
mois à compter de la date de l’ordre de service prescrivant le commencement des
prestations.
Les durées de réalisations de chacune des phases du marché sont comme suit :
Phase Mission Durée
Phase 1 Installation, paramétrage, 12 mois à compter date de l’ordre de

interfaçage, test et mise en service service prescrivant le
du Système des Opérations commencement de la phase 1
Aéroportuaires Multiplateformes
(SOAM) conforme au présent cahier
des charges au niveau des aéroports
de Casablanca,
Marrakech et Rabat

des charges au niveau des aéroports
de Tanger, Agadir, Fès,
Oujda et Nador

des charges pour les 14 autres
aéroports
La Phase 2 et la Phase 3 peuvent être menées simultanément.
Chaque phase du projet fera l’objet d’un ordre de service partiel.
ARTICLE 16 : DESCRIPTION DU PROJET
1. INTRODUCTION
Lóbjectif de ce projet est dáméliorer léxpérience des passagers et la capacité des
plateformes aéroportuaires à travers límplémentation de systèmes déjà existants sur le
marché.
Les besoins et les enjeux qui motivent cette extension et mise à jour de nos systèmes peuvent
se résumer comme tel :
• Aider à gérer la croissance de lÓNDA en améliorant les conditions de traitement des

passagers et des opérations aéroportuaires :
o LÓNDA a connu une croissance de plus de 3.5% des passagers au sein des
aéroports sur les 2 dernières années. Ceci a engendré une augmentation
de la complexité des infrastructures et des opérations.
• Aider à gérer le risque :
o Avec la collection potentielle de données personnelles au sein des
aéroports et face à la criticité du transport aérien dans l’économie du
Royaume, il est indispensable de se protéger face au vol ou à la perte
d’information et les arrêts des systèmes de productions. Les plateformes
aéroportuaires doivent obligatoirement être sécurisées contre les accès
non autorisés, physiques ou virtuels. Ces obligations sont essentielles pour
être en conformité face aux contraintes légales imposées par les différents
organismes - sécuritaires locales, IATA, OACI – afin de maintenir la
catégorie internationale de nos aéroports.
• Permettre de rester flexible :
o LÓNDA doit pouvoir réduire les coûts opérationnels et de propriété en
améliorant la flexibilité et la mise à disposition des niveaux de services
demandés par l’activité des aéroports.
• Créer de la valeur :
o Les systèmes d’information doivent pouvoir être utilisés de manière nouvelle
pour générer de la valeur, soit en augmentant la productivité et la
capacité des infrastructures actuelles, soit en créant de nouvelle source de
revenue pour lÓNDA.
Année 2017
Aéroports
Mouvements Passagers
MOHAMMED V 85 712 9 364 861
MARRAKECH 31 666 4 366 028
AGADIR 12 486 1 544 244
FES 8 310 1 116 095

TANGER 10 671 1 074 177
RABAT-SALE 7 019 924 686
NADOR 5 857 706 979
OUJDA 5 431 635 746
LAAYOUNE 2 175 206 274
DAKHLA 1 575 168 552
ESSAOUIRA 748 83 414
AL-HOCEIMA 894 72 044
OUARZAZATE 1 040 65 010
TETOUAN 610 23 793
ERRACHIDIA 385 18 149
TAN-TAN 516 12 170
GUELMIM 504 11 095
BENI-MELLAL 263 6 598
ZAGORA 214 5 872
BOUARFA 4 110
BENSLIMANE 14 28
IFRANE 0 0
Total 176 094 20 405 925
LÓNDA désire implémenter les nouveaux systèmes et processus en trois phases. La

première phase inclue les aéroports de Casablanca – Mohammed V, Marrakech -
Menara et Rabat - Salé. Une fois les systèmes implémentés avec succès sur ces trois
plateformes aéroportuaires, les nouveaux systèmes seront déployés sur les aéroports
d’Agadir, Tanger, Fès, Oujda et Nador dans une deuxième phase et généralisé vers les
autres aéroports gérés par lÓNDA dans la troisième phase.
Cela implique que, durant la phase initiale, les nouveaux systèmes implémentés pourront
fonctionner parallèlement aux systèmes actuels déployés au niveau des aéroports.
Actuellement, le système d’information de gestion aéroportuaire de lÓNDA contient les

systèmes suivants :
Un système d’information aéroportuaire (SIA) formé d’un module de gestion de vol

•
(Téléaffichage) et d’un module de facturation aéronautique.
• Un système de traitement de passagers formé d’un module CUTE et d’un module BRS.
LÓNDA désire mettre en place dans un premier temps un Système des Opérations
Aéroportuaires Multiplateformes (SOAM) intégré, fondé autour dúne base de données
aéroportuaire (AODB) et communiquant avec les autres systèmes déployés dans les
aéroports.
Les systèmes suivants font partis du SOAM à mettre en place :
- AODB (Airport Operational Database)

- Plateforme díntégration
- Système de gestion de ressources (Resource Management System)
Ce sont tous des systèmes complexes qui vont nécessiter une intégration au sein des
systèmes actuels de lÓNDA, une gestion du changement, une gestion des risques et un
support post implémentation.
Le Système dÓperations Aéroportuaires Multiplateformes (SOAM) comprendra une

base de données aéroportuaire (AODB), capable de gérer les données des 22
aéroports. Il inclura un système de gestion de ressources aéroportuaires (RMS) pour au
minimum les huit aéroports principaux, et pourra s’interfacer avec les systèmes existants
à lÓNDA. Le SOAM devra permettre límplémentation dún système de gestion de
décision collaborative aéroportuaire (A-CDM) dans un futur proche sur une partie des
plateformes aéroportuaires.
Dans le cadre de ce projet le prestataire doit proposer une solution SOAM (logicielle et
matérielle) clé en main.
2. SYSTÈMES ACTUELS
2.1. SYSTEME DÍNFORMATION DE VOL
Le système dínformation de gestion des vols (FIDS) a été développé par la société TISYS,
aujourd´hui propriété d’Ultra Electronics Airport Systems. Ce système baptisé AIRVISION
a été modifié pour répondre aux besoins spécifiques de lÓNDA.
Le système de gestion des vols (AIRVISION) est initialement pré-renseigné par une
information saisonnière et opérationnelle de la journée. Il est mis à jour au travers de la
réception automatique de message type B provenant des compagnies aériennes ou
dássistance au sol (SVS) pour chaque départ et arrivée. Ces messages sont traités à
travers un « parser » - que lón peut traduire par un éditeur de messages automatisé. Les
changements d´horaires peuvent aussi être renseignés par email ou par téléphone. Le
système de téléaffichage permet l’affichage des informations d’AIRVISION sur les écrans,
selon le paramétrage de chaque écran.
Aujourd’hui, les compagnies aériennes ne peuvent pas mettre à jour elles-mêmes les
informations en cas de retard ou dérreurs ni afficher des messages spécifiques sur les
écrans de téléaffichage.
Líntention de lÓNDA est de mettre en place une AODB et de conserver AIRVISION

uniquement pour le système dáffichage de vol (FIDS) et qui sera alimenté à partir de la
nouvelle AODB directement ou à travers la Plateforme dÍntégration (PI-ESB).
2.2. SYSTEME DE FACTURATION
Le système de traitement de données qui permet de générer la facturation baptisé

AIRFACT a été développé par la société TISYS. Ce système a été modifié pour répondre
aux besoins spécifiques de lÓNDA. Il se compose dúne base de données centrale
installée au siège de lÓNDA permettant de centraliser l’édition des factures et des bases
de données locales avec leur propre logiciel de gestion localisées dans chaque
aéroport pour le renseignement de données et l´édition de factures au comptoirs, et
dún système de réplication entre les bases de données locales et la base de données
centrale.
Les systèmes de gestion des vols (AIRVISION) et de facturation (AIRFACT) sont initialement
pré-renseignés au travers de la réception automatique de message type B provenant
des compagnies aériennes (MVT, SVS, LDM, etc.) pour chaque départ et arrivée.
Chaque aéroport dispose dúne adresse type B centralisée au siège de lÓNDA qui,
ensuite, redistribue les messages à travers son réseau. Ces messages sont traités à travers
dún « parser » - que lón peut traduire par « éditeur de messages automatisés » – qui a
été développé pour lÓNDA.
Il n’est pas prévu de remplacer le système de facturation mais il est prévu que celui-ci
soit modifié pour accepter les données provenant de l’AODB directement ou à travers la
Plateforme dÍntégration (PI-ESB).
3. DÉCOMPOSITION DU MARCHÉ
Le marché est constitué de Trois parties :

• Partie 1 : Implémentation d’un SOAM (AODB, plateforme d’intégration PI-ESB et
RMS) standard du marché conforme au présent cahier des charges au niveau
des aéroports de Casablanca, Marrakech et Rabat o Lancement o Cadrage
technique des modalités d’implémentation o Expression des besoins o
Spécifications détaillées o Installation du SOAM o Paramétrage et
développements
o Mise en qualité et reprise des données de référence o Intégrations aux autres
applications à travers la plateforme díntégration o Tests de fonctionnement o
Tests d'intégration o Fonctionnement en parallèle avec les autres plateformes o
Formation des utilisateurs
o Mise en production
• Partie 2 : Implémentation d’un SOAM (AODB, plateforme d’intégration PI-ESB et

RMS) standard du marché conforme au présent cahier des charges au niveau
des aéroports de Tanger, Agadir, Fès, Oujda et Nador o Lancement o Cadrage
technique des modalités d’implémentation o Expression des besoins o
Spécifications détaillées o Installation du SOAM o Paramétrage et
développements
o Mise en qualité et reprise des données de référence o Intégrations aux autres

applications à travers la plateforme díntégration o Tests de fonctionnement o
Tests d'intégration o Fonctionnement en parallèle avec les autres plateformes o
Formation des utilisateurs
• Partie 3 : Implémentation d’un SOAM (AODB et plateforme d’intégration PI-ESB)

standard du marché conforme au présent cahier des charges pour le reste des
aéroports
o Lancement o Cadrage technique des modalités d’implémentation o
Initialisation du SOAM
o Mise en qualité et reprise des données de référence
o Intégrations aux autres applications à travers de la plateforme díntégration
o Tests de fonctionnement o Tests d'intégration o Formation des utilisateurs
La partie 2 et la Partie 3 peuvent être menées simultanément.
4. BASE DE DONNEES OPERATIONNELLE AEROPORTUAIRE (AIRPORT OPERATIONAL DATA

BASE)
L'AODB est la base de données centrale d'exploitation pour les opérations
aéroportuaires. L'AODB doit contenir toutes les données nécessaires à l'identification en
temps réel des vols, des compagnies aériennes, de l'utilisation des ressources, etc. En
outre, lÁODB fournira des données à des fins administratives, aux systèmes de
facturation, de production de statistiques et de production de rapports.
La plateforme díntégration (PI-ESB) assure la communication entre les applications

aéroportuaires hétérogènes. Elle doit être en mesure d'envoyer/recevoir des informations
à des entités externes et de les intégrer aux systèmes aéroportuaires existants, en utilisant
des logiciels à protocole ouvert pour permettre l'incorporation d'équipements de
marques différentes.
L'AODB et la plateforme díntégration (PI-ESB) devraient être basés sur des solutions COTS
et nécessitent une adaptation minimale pour répondre aux besoins des utilisateurs.
La technologie à utiliser doit être à la fine pointe de la technologie, modulaire en matériel et

logiciel, afin de minimiser et d'isoler facilement les défaillances possibles.
L'équipement demandé doit être de marque de prestige reconnue, qui présente des
niveaux élevés de fiabilité et de disponibilité. De même, il devrait pouvoir fonctionner à
capacité réduite sans dégradation du service et permettre un accès à distance pour
l'entretien ou la reconfiguration en usine si nécessaire.
La conception du système devrait comporter des facilités d'évolutivité pour permettre la

croissance du système, avec seulement l'agrégation matérielle et logicielle.
L'architecture de l’AODB et la plateforme díntégration (PI-ESB) devrait permettre la

définition centralisée des utilisateurs et des rôles, avec la possibilité de configurer
différents niveaux d'accès aux applications et aux données.
L'AODB et la plateforme díntégration (PI-ESB) devraient être facilement extensibles et

configurables, notamment en ce qui concerne l'ajout ou la suppression de services
(nouveaux écrans, nouveaux types d'informations ou nouvelles sources de données à
contrôler).
4.1. SPÉCIFICATIONS FONCTIONNELLES DE L’AODB ET PI-ESB
4.1.1. AUTHENTIFICATION ET CONTROLE D'ACCES
a. Le système devrait utiliser des mécanismes de connexion au serveur, au poste

de travail et à l'application par le biais d'un nom d'utilisateur et d'un mot de
passe.
b. Le système doit permettre à un administrateur système de restreindre l'accès
d'un utilisateur à tout composant du système.
c. Le système doit permettre l'authentification des utilisateurs et l'accès aux
ressources par le biais du LDAP, dÁctive Directory et/ou de l'annuaire actif
des aéroports.
d. Le système doit permettre la définition des rôles et/ou des profils associés aux
niveaux de sécurité et aux droits d'accès.
e. Le système devrait fournir des mécanismes de contrôle pour accéder aux
données stockées dans la base de données, permetant de créer, interroger,
mettre à jour, effacer les données et les tableaux en fonction des profils des
utilisateurs finaux et des techniciens.
f. Le système devrait prévoir la possibilité d'activer des mécanismes d'audit
pour les données et/ou les tableaux.
Horloge
a. Le système doit permettre d'utiliser les horaires UTC ou le fuseau horaire local.
b. Le système doit utiliser le service NTP.
Interface utilisateur final
a. Le système devrait fournir une interface utilisateur final basée sur l'utilisation de
fenêtres conviviales
b. Le système doit pouvoir être multilingue au moins (Français, espagnol, anglais)
et permettre la configuration et la sélection de la langue francaise pour les
utilisateurs finaux.
c. Le système doit permettre l'utilisation de couleurs pour configurer les alertes et
les événements liés au vol
d. Le système doit permettre l'utilisation de filtres sur les écrans des différents
modules du système.
e. Le système doit utiliser et être compatible avec les codes IATA, OACI pour les
codes d'aéroport, pays, villes, compagnies aériennes, types d'aéronefs.
4.1.2. SPÉCIFICATIONS FONCTIONNELLES DU SYSTÈME AODB
1- Saisie, enregistrement et traitement des données

a. L'AODB fournira les informations essentielles au bon fonctionnement des
processus internes de l'aéroport, ainsi que des processus associés aux
compagnies aériennes, aux compagnies dássistance au sol et aux
organisations aéroportuaires.
b. L'AODB aura une interface utilisateur graphique (GUI). L'interface

graphique permettra à un utilisateur autorisé d'ajouter, de modifier ou de
supprimer manuellement des champs associés à un vol. Les écrans
d'entrée (formulaires) faciliteront la saisie de toutes les données, aucune
donnée ne sera enregistrée directement dans les tableaux de données
sans verification par le systeme.
c. Le système doit être intuitif et facile à utiliser (basé sur une interface
graphique configurable). Il doit prendre en charge la technologie client
léger afin d’assurer la mobilité du personnele de l’aéroport.
d. L'AODB devrait saisir et stocker des données pertinentes pour son
fonctionnement à partir de systèmes internes et externes. Les sources des
données peuvent être:
i. Mise à jour manuelle par les compagnies aériennes, les compagnies
dássistance au sol ou les autorités aéroportuaires.
ii. Mise à jour automatique par les compagnies aériennes, les compagnies
dássistance au sol ou les autorités aéroportuaires (à travers des
processus tel que chargement feuille Excel contenant des mises à jour,
etc…)
iii. Mise à jour à travers des messages IATA ou tout autre programme
d'alimentation, tel que SITATEXT.
iv. Mise à jour par le personnel de l’aéroport
e. Tous les mouvements d'aéronefs doivent être enregistrés et tracés. Ceci
inclut, par exemple, l'enregistrement des informations suivantes :
i. Heures d'arrivée et de départ prévues
ii. Heures réelles d'arrivée et de départ
iii. Temps bloc en position de parking (On Block, off block)
iv. Remorques pour places de stationnement (Heures prévues et réalisées)
f. Les passagers à l'arrivée et au départ doivent être enregistrés pour chaque
vol, répartis au moins en :
i. Passagers payants
ii. Enfants iii. Diplomates iv. Autres passagers exonérés de taxes
v. Passagers en transit
vi. Passagers PMR (a mobilite reduite utilisant un acces avec assistance et
fauteuil roulant)
g. Le système doit fournir une interface utilisateur conviviale pour la création
et la gestion des règles métier et opérationnelles, sans programmation et
sans dépoendance vis-àvis des fournisseurs.
h. La solution doit adopter une démarche basée sur des règles pour fournir les
fonctionnalités couvrant tous les composants du logiciel.
i. Toutes les règles métier doivent avoir une période de validité permettant
d’adapter la solution avec souplesse à l’évolution des méthodes
d’exploitation de l’aéroport actuellement et dans le futur.
j. La solution doit permettre d’adapter la base de règles aux conditions
d’exploitation réelles.
k. Les enregistrements de vol doivent être conservés actifs pendant 45 jours
au minimum. Un système de stockage des données à long terme devrait
être mis en place, dans lequel l'archivage des données qui ne sont plus
actives et qui facilitent l'accès à l'information et son extraction devrait être

enregistré.
l. L'AODB devrait gérer les vols quotidiens et saisonniers.
m. Le système doit permettre à plusieurs opérateurs d’accéder aux mêmes
données simultanément. L’actualisation et la synchronisation des données
doivent s’effectuer entiérement en temps réel, sans aucune intervention
de l’utilisateur.
n. Le système doit proposer une fonction annuler/rétablir permettant ainsi aux
utilisateurs de tester une fonctionalité et de revenir à l’état d’avant si
nécessaire.
o. Le système doit aider à détecter toute situation irrégulière survenant dans
un aéroport et susceptible d’avoir des répercusions négatives sur le
processus et les niveaux de service en aval, et doit aider à agir en
conséquence. Il doit être possible de visualiser ces situations sur des
tableaux de bord en temps réel. Ces tableaux de bord doivent être
configurables par les utilisateurs de l’aéroport autorisés. Cette
fonctionnalité doit être realisée soit au sein de lÁODB, soit au sein du
système de gestion de ressources (RMS).
p. Le système doit permettre aux utilisateurs autorisés de
verouiller/déverouiller les données relatives aux mouvements de vol.
q. Il doit être possible de séparer les alertes en fonction des rôles ou de
distribuer toutes les alertes à tous les utilisateurs.
r. Un système de traçage de tout les événements liés à un vol (modification
des données, nom de l’utilisateur qui a modifié les données, heure de
modification des données, identification de la station depuis laquelle ont
été modifiées les données, etc) devra être mis en place pour des raisons
de securité.
2- Les informations suivantes sont requises au minimum pour les opérations aéroportuaires
:
a. Nature du vol
i. Adresse (matricule pays d'arrivée/départ)
ii. Type de vol (planifié, charter, cargo, militaire, aviation generale,
ambulance.... etc.)
b. Informations affichées pour la compagnie aérienne
i. Le nom de la compagnie aérienne (IATA)
ii. Code de partage (codeshare) des lignes aériennes (IATA)
c. Nom de la compagnie aérienne
i. Nom abrégé de la compagnie aérienne
ii. Nom de la compagnie aérienne
iii. Autre nom de compagnie aérienne
iv. Groupe dápartenance de la compagnie aériene (si il y a lieu)
v. Alliance marketing de la compagnie aérienne (Skyteam, Star
Alliance, OneWorld) Si il y a lieu
d. Informations sur le vol
i. Numéro de vol
ii. Numéro d'exploitation du vol

iii. Code partage de code vol(s)
e. Temps de vol
i. Date et heure du vol régulier (arrivée/départ) (schedule)
ii. Date et heure approximative du vol d'arrivée/départ (ETA/ETD)
iii. Date et heure réelles d'arrivée et de départ du vol (Touchdown et
Take off) iv. Date et heure réelles du stationement de l’aeronef et
de sa sortie de stationement (Heures Bloques)
f. Informations sur l'itinéraire
i. Destination - Voie 1, Voie 2 Voie 3 (norme IATA - en amont de trois villes
précédentes)
ii. Origine - 1,2 de 3 (norme IATA – jusqu’à trois villes en aval)
g. Renseignements sur l'aéronef
i. Type d'aéronef (IATA)
ii. Sous-type d'aéronef (IATA)
iii. Autre type d'aéronef
iv. Matricule des aéronefs
v. Poids Maximum au décollage (MTOW) de l’aeronef
h. Emplacement et ressources du vol
i. Identification du terminal
ii. Nom du terminal
iii. Porte assignée
iv. Porte précédente assignée
v. Temps de fermeture de la porte
vi. Temps d'ouverture de la porte
i. Information sur l ássistance au sol
i. Identification de la manutention/ société de service au sol
ii. Autre identification des fournisseurs de services
iii. Livraison de nourriture (Oui/Non) (Catering)
j. État
i. Code d'état du vol
ii. Texte libre pour les observations de vol
iii. Code de confirmation
iv. Autres domaines d'activité
k. Horaires des vols
i. Code
ii. Adresse (arrivée/départ) iii. Fréquence (quotidienne, hebdomadaire,
bihebdomadaire... etc.) iv. Date de début de saison du vol
v. Date de fin de saison du vol
vi. Autres domaines (ligne aérienne, type d'aéronef, etc.).
3- Personnalisation
a. La solution doit permettre l'ajout/ la suppression d'un nombre illimité de
champs personnalisés afin qu'il soit possible d'obtenir le niveau de détails
nécessaire dans la description des données de vol. Ces champs peuvent
être de type Nombre entier, Double, Chaîne, Booléen, ou DateHeure.
b. La solution doit permettre d'ajouter/ de supprimer des tables de données

configurables associées à des vols et pouvoir contenir des informations
opérationnelles de longueur variable (par ex., liste de partages de code,
codes de retard, passagers spéciaux, etc.).
c. Le système doit prendre en charge les codes IATA et OACI. Les deux
systèmes de codification peuvent être utilisés indifféremment et
simultanément dans les affichages, les configurations, les règles, etc.
d. Le système doit donner la possibilité de configurer en cascade plusieurs
étapes de calcul à l'aide de règles facilement configurables.
e. Le système doit permettre de définir des règles de validation de données
entièrement configurables et permettre d'alerter les utilisateurs en cas
d'incohérences. Si nécessaire, il doit être possible de configurer ces règles
de manière à empêcher l'utilisateur de saisir des données contradictoires
ou erronées. En pareil cas, la raison pour laquelle les données sont erronées
doit être expliquée à l'utilisateur en fonction du contexte. (le système doit
avoir 2 niveaux de règles : Règles inviolables que le système rejettent et les
règles « de preferences » ou « alertes » qui redemandent à l’utilisateur de
confirmer les données qu’il est en train de saisir).
f. L'utilisateur doit pouvoir afficher des indicateurs de qualité des données
mettant en évidence les problèmes potentiels qui doivent être résolus.
4- Gestion du vol saisonnier
a. Le système doit permettre l'établissement de programmes de vols
saisonniers et la pré-allocation des ressources sur les saisons à venir.
b. Le système doit être doté de mécanismes automatiques ou manuels pour
la saisie et l'enregistrement des horaires de vols saisonniers à partir de
systèmes externes, avec différents types et formats de fichiers.
c. Le système doit générer des informations quotidiennes sur les vols à partir
des horaires de vols saisonniers.
d. Chaque mouvement de vol doit être considéré comme un enregistrement
unique dans le système, indépendamment de la planification. La gestion
d’un vol en temps réel ne doit entraîner aucune perte de fonctionnalité à
n’importe quel moment situé dans l’avenir ou le passé(où un vol annulé
n’annule pas les vols prévus dans la base pour le reste de la saison, etc..).
5- Gestion quotidienne des vols
a. Le système doit permettre l'exploitation et le mouvement quotidiens des
aéronefs et des ressources, automatiques ou manuels, sur la base des
informations disponibles et reçues des différents systèmes internes et
externes intégrés au SOAM.
b. Le système doit permettre l'enregistrement et la gestion des vols ne
provenant pas d'horaires saisonniers, tels que les vols non planifiés des
compagnies aériennes, les vols dáviation generale, etc.
c. Le système doit être en mesure d'ajuster la planification quotidienne des
incidents, tels que l'annulation, le retard, les écarts, les changements
d'itinéraire, etc.
d. La programmation opérationnelle quotidienne doit contenir au moins les
informations suivantes:
i. Heures d'arrivée ou de départ prévues. ii. Portes de vol réelles.

iii. Carrousels/pistes pour les vols d'arrivée. iv. Livraison des Premiers
et dernier bagage pour les vols d'arrivée.
v. Les types d'aéronefs et catégories.
vi. Les numéros d'immatriculation
vii. Positions de stationement de láeronef
viii. état du vol.
ix. Opérations irrégulières pour les vols à effectuer, retour au bloc,
déroutement et annulation
x. Nombre de passagers par homme, femme, enfant.
xi. Nombre de passagers pour les vols et par classe de service.
xii. Nombre de passagers exempt de taxe
xiii. Comptage des passagers nécessitant une assistance spéciale pour les
vols et type d'assistance.
6- Gestion de la facturation :
le système doit être en mesure de communiquer toutes les informations pertinentes
pour le système de facturation.
7- Base de données
a. Le système doit fournir un enregistrement centralisé pour la définition et la
configuration de toutes les données/paramètres relatifs aux informations
de vol et aux ressources aéroportuaires.
b. Le système doit permettre la validation des données, saisies manuellement
ou par le biais d'interfaces automatiques, en utilisant des configurations et
des définitions enregistrées dans la base de connaissances.
c. Le système doit permettre, sur la base des données, de gérer :
i. Informations aéroport en route, sélectionnables par code IATA aéroport.
ii. Obtenir des informations des exploitants d'aéronefs, sélectionnables par
le code IATA de la compagnie aérienne
iii. Obtenir les données de l'aéronef exploité à l'aéroport, sélectionnables
par le code IATA de l'aéronef
iv. Détails des configurations spécifiques sélectionnables par numéro
d'immatriculation de l'aéronef.
L'AODB doit disposer d'interfaces permettant d'importer des informations sur les vols
(calendrier saisonnier ou mises à jour quotidiennes) des compagnies aériennes, des
sociétés dássistance au sol et/ou des organismes gouvernementaux, selon le cas.
8- Interfaces associées aux systèmes aéroportuaires.
LÁODB devra être intégrée avec le système de gestion de ressources (RMS). Cette
intégration doit être en mode « natif » cést à dire ne nécessitera pas obligatoirement
de passer par la plateforme díntégration (PI-ESB)
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB), devrait échanger

des informations avec au moins les systèmes suivants : I. TAPIS/CUPPS
a. CUPPS – AODB : Etat des comptoirs et des portes (ouverts, fermés), fermeture du
vol, nombre de passagers.
II. BHS (Baggage Handling System) et BRS (Baggage Reconciliation System)
b. AODB – BHS : Renseignements sur les vols, planification, changements et
assignation des positions de stationnement des aéronefs et tapis bagages.
c. BHS – AODB : Premier/dernier bagage.
III. ATC
d. AODB – ATC : information de vol, planification, changements.
e. ATC – AODB : autorisation d'atterrissage, matricule de láeronef, heures
d'atterrissage et décollage.
N.B : l’échange d’information entre AODB et ATC sera réalisé avec l’aide du pôle navigation
aérienne s’il le souhaite.
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB), fournit des informations

aux systèmes suivants :
a. FIDS : Informations de vol contenues dans l'AODB à afficher en temps réel sur les
écrans et les terminaux distribués dans différentes zones de l'aéroport (arrivées,
départs, embarquement, etc.). Le flux d'information doit prendre en compte les
informations nécessaires aux passagers et aux usagers des aéroports comme le
nombre et le type de vol, la compagnie aérienne, l'origine, la destination, la date et
l'heure d'arrivée et de départ, le terminal, le comptoir, la porte d'entrée, la
déclaration des bagages, etc.
b. Site web ONDA : pour alimenter le site web ONDA par le programme de vols.
c. Site Web de la DGAC : pour alimenter le site web de la DGAC par le programme de
vols.
d. Application Mobile : pour alimenter une application qui affiche le programme de vols
sur smartphone.
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB), doit recevoir des

informations au moins des systèmes suivants :
a. SITATEX/ARINC – Messages type B : Informations sur les mouvements et horaires (heure

d'arrivée/départ estimée, etc.), les previsions saisonieres des compagnies
(SSM), le nombre de passagers, etc
b. AFTN : plan de vol, informations sur les aérodromes de décollage, d'arrivée, de départ
et de destination, NOTAMS, etc.
c. Information météorologique externe : renseignements météorologiques sur l'origine et
la destination du vol
N.B : l’échange d’information entre AODB et AFTN sera réalisé avec l’aide du pôle navigation
aérienne s’il le souhaite.
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB), doit fournir, en temps réel,
des renseignements sur les vols liés à l'utilisation des portes contacts d'embarquement ou de
positions éloignées aux différents intervenants : Compagnies aériennes, compagnies
dássistance au sol, etc.
Précisant, par exemple, l'heure d'ouverture de l'embarquement, l'heure d'arrivée des bus à
la position éloignée ainsi que les données suivantes :
• Code de vol
• Porte d'embarquement
• Position éloignée
• Date et heure programmées
• Date et heure de lóperation effective
• Date et heure de disponibilité du pont d'embarquement
• Date et heure de disponibilité des véhicules terrestres
• Nombre de véhicules terrestres
L'AODB, à travers la plateforme díntégration (PI-ESB), doit fournir des renseignements sur
les vols en ce qui a trait à l'heure d'utilisation du pont d'embarquement, aux heures
d'utilisation de la position de stationnement, à l'utilisation des véhicules terrestres, à
l'alimentation électrique, à l'eau potable et à la climatisation.
Avec ces informations et les tarifs correspondants associés aux types d'aéronefs, selon
les vols domestiques et internationaux, le système SOAM devra générer des informations
de pré-facturation qui permettront d'enregistrer les éléments suivants :
• Position de contact vols intérieurs
• 30 premières minutes ou fraction de demi-heure ou fraction d'heure supplémentaire
• Services connexes
• Services dÉau, dínternet et d'énergie électrique
• Position à distance de la climatisation
• Transport terrestre de véhicules
• Débarquement des véhicules terrestres
• Vols internationaux Position de contact
• Utilisation des lumières de piste (balisage)
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB), doit fournir, en temps

réel, des renseignements sur les vols liés au type d'aéronef (code OACI) et au type de
vol (code OACI et domestique, international) incluant les points d'embarquement ou les
positions de stationnement éloignés pour préparer leur départ ou leur décollage. Ces
informations seront transmises au système de facturation.
L'AODB, par l'intermédiaire de la plateforme díntégration (PI-ESB) fournit, pour chaque

vol de départ, des informations sur les passagers embarqués, la distance parcourue et le
type de vol (national, international). Ces informations seront transmises au système de
facturation.
9- Statistiques
a. Le système devrait permettre l'édition de rapports par heure, quotidien,

hebdomadaire, mensuel et annuel.
b. Le système doit permettre l'enregistrement, la traçabilité et la génération de résumés
associés aux données de performance telles que: nombre de messages par interface
(envoi et réception), nombre de messages pour une période de (envoi et réception),

nombre d'erreurs, nombre de connexions.
c. Toutes les statistiques doivent être accessibles en texte et/ou sous forme de graphiques.
d. Toutes les statistiques seront exportables dans des fichiers texte et Excel.
e. Ces statistiques doivent pouvoir être générées automatiquement à intervalle régulier
configurable par outil standard, avec sauvegarde sur serveur de fichier.
f. La solution de production de rapport doit fonctionner en temps réel, par exemple offrir
un moyen d'assurer une vigilance opérationnelle (surveillance en temps réel de la
capacité des avions, profil des passagers pour l'enregistrement et délai d’attente à
l’aéroport, etc.) et KPI (ponctualité des avions, etc.).
g. Le schéma de la base de données de DataWarehouse doit être publié et extensible.
4.2. SPÉCIFICATIONS TECHNIQUES DE L’AODB ET PI-ESB
4.2.1. GENERALITES
1- AODB et la plateforme díntegration (PI-ESB) s'appuieront sur une architecture de

dernière génération (client/serveur et/ou clustering, …etc.).
2- Le fournisseur doit offrir une architecture centralisée pour l’ensemble des
aéroports dans un premier Core Room au site central à l’aéroport de Casablanca
et dans un dual core Room au site de backup situé à 2 Km de l’aéroport de
Casablanca.
3- La solution doit permettre de gérer simultanément plusieurs plateformes
aéroportuaires sur la base de la même configuration matérielle et logicielle.
Cette solution doit être basées notamment sur :
a. Des serveurs performants en vitesse de traitement et capacité de stockage.
b. Des bases de données et tables uniques consolidant les informations de vol,
etc. des aéroports centralisés.
c. Des données de référence uniques pour les aéroports centralisés.
d. Des données de configuration et de règles d’exploitation configurables
potentiellement différentes par aéroport.
e. Des vues, masques, écrans, codes couleurs, etc. configurables
potentiellement différentes par aéroport.
f. Une reconfiguration dynamique des droits d’accès au travers des différents
aéroports. Certains utilisateurs pouvant accéder à plusieurs aéroports, d’autres
étant limités à des aéroports particuliers.
g. Les états des vols dans un aéroport peuvent être utilisés pour déterminer les
états des vols dans un autre aéroport géré par la même solution
h. Un entrepôt de données « datawarehouse » consolidé contenant les données
des aéroports centralisés, permettant des tableaux de bord généraux, sans
que des requêtes multi- base de données soient nécessaires.
i. La configuration multi-aéroports doit pouvoir être gérée complètement à
distance, et dynamiquement. Par exemple, l’ajout de règles d’exploitation, ou
de nouvelles ressources dans un aéroport ne doit pas impacter les autres
aéroports, et doit pouvoir s’effectuer sans avoir besoin de redémarrer le
système.
La plateforme matérielle proposée doit être redondante au niveau du site principal à

l’aéroport de Casablanca et au niveau du site de backup situé à environ 2 km de
l’aéroport de Casablanca pour assurer la haute disponibilité du système.
La liaison FO SMF (Single Mode Fiber) entre le premier Core room du site principal et le
dual Core room du site backup sera fournie par l’ONDA. Le prestataire aura à sa charge
la fourniture des Switchs réseau et la connexion du site principal avec le site de backup.
5. PLATEFORME DÍNTEGRATION (PI-ESB)
5.1. CONTEXTE
L'ONDA s'engage dans une initiative d'intégration de ses systèmes, pour une gestion en
temps réel et automatisée des informations. Pour ce faire, la mise en œuvre dúne
plateforme díntégration - Entreprise Service Bus (PI-ESB) est essentielle à cette initiative.
Ce module concerne la fourniture dúne solution complète PI- ESB et l'intégration de tous les
systèmes de láéroport fournissant des données critiques.
Pour mettre en œuvre la solution PI-ESB de la meilleure façon, celle-ci doit prendre en
charge les opérations aéroportuaires clés et offrir un standard díntégration des
applications à travers une plateforme sécurisée permettant un échange fluide des
données en vertu d'une architecture orientée service (SOA).
5.2. PORTEE DU PROJET

Le système doit pouvoir :
1- Permettre l'interconnexion et l'échange de messages et d'informations entre les
systèmes aéroportuaires, les systèmes basés sur des dispositifs ou terminaux, les
systèmes associés aux compagnies aériennes et les systèmes associés au trafic aérien.
2- Permettre et contrôler le transfert synchrone ou asynchrone de messages et
d'informations, permettant de définir les délais de livraisons des messages, le nombre
de tentatives de livraison, etc.
3- Recevoir et envoyer des messages en XML, HTTP, formats SOAP vers et à partir de
différents systèmes.
4- Recevoir et envoyer des fichiers via FTP/SFTP depuis et vers différents systèmes.
5- Recevoir et envoyer des requêtes SQL, via ODBC, JODBC connexions vers et à partir
de différents systèmes
6- Permettre l'utilisation des échanges de messages et d'informations à travers l'utilisation
de technologies basées sur les SERVICES WEB, SOA, REST, JSON etc.
7- Permettre l'échange de messages et d'informations, en utilisant des mécanismes de
sécurisation tels que le cryptage, les certificats numériques, etc.
8- Permettre la possibilité d'échanger des messages et des informations au moyen de
mécanismes de traduction ou de conversion de données (par exemple, codes IATA
traduient en code OACI et vice versa).
A- Transaction
1- Le système permettra de configurer une nouvelle interface ou de mettre à jour

une interface existante d'une manière simple et sécurisée, en tenant compte de
l'identification de l'expéditeur/récepteur, du nombre et de la durée maximale des

messages associés à une file d'attente, etc.
2- Le système devrait avoir des mécanismes pour définir et contrôler le routage,
l'envoi/réception et la purge des messages en fonction de différents critères.
3- Le système devrait disposer d'outils pour surveiller, arrêter et activer les interfaces,
en tenant compte de la génération d'alertes et d'alarmes si c’est possible par
courrier électronique ou par messagerie.
4- Le système devrait fournir des mécanismes et des outils pour contrôler, réconcilier
et déboguer les messages erronés ou en attente, compte tenu de l'identification
des causes et des mesures prises.
Le système devrait permettre à lÓNDA de développer seul des interfaces avec de nouveaux
systèmes sur la base de connecteurs et API inclus dans plateforme livrée.
B- Supervision
1- Le système doit être en mesure de maintenir la traçabilité pour les échanges

commerciaux.
2- Le système devrait fournir des outils permettant de surveiller les connexions en temps
réel.
3- Le système devrait fournir des possibilités de notification de la situation générale et de
l'état du système en temps réel par le biais de l'interface graphique, du courrier
électronique, des SMS.
4- Le système doit être capable de fournir un tableau de bord sur les indicateurs clès.
5.3. INTEGRATIONS
A- Généralités
Les formats d'échange d'informations peuvent être hétérogènes, provenir de sources

différentes et devraient permettre l'incorporation de nouveaux champs si nécessaire.
L'envoi et la réception d'informations devraient, dans la plupart des cas, se faire en temps
réel et devraient être mis en œuvre à l'aide de protocoles ouverts tels que XML, SOAP,
etc.
Les interfaces détaillées dans le présent document doivent être opérationnelles après la mise
en œuvre de la solution pour l’ONDA.
La solution Plateforme dÍntégration - Enterprise Service Bus (PI-ESB) intègrera donc la

suite « Systèmes des Opérations Aéroportuaires Multiplateformes (SOAM) » mais ne se
limite pas à ce qui suit :
• Base de données opérationnelle aéroportuaire (AODB) et DataWarehouse (DW).
• Plateforme intégration - Enterprise Service Bus (PI-ESB).
• Système de gestion des ressources (RMS).
• Système de gestion dínformation de vol, de KPI et de statistiques.
• Solution de réconciliation bagages (BRS)

• Système d'affichage des informations de vol (FIDS)
• Équipement terminal à usage commun (CUPPS), kiosque à usage commun (CUSS) et
Bag Drop.
• Système de facturation aéronautique et statistiques (AIRFACT)

• Messagerie électronique aéronautique tel que message type B et messages
AFTN/AMHS
• Application mobile (guide horaire)

• Interface comptable avec ERP Oracle
• Interface Radar
B- Etapes de la mise en place de la plateforme d’intégration

Le fournisseur doit fournir une solution clé en main complète de
Plateforme dÍntégration - Enterprise Service Bus (PI- ESB) afin d'intégrer plusieurs
nouveaux systèmes et services à l’ONDA.
Pour la mise en place de cette plateforme d’intégration, le fournisseur est appelé à suivre les
étapes suivantes (ou équivalentes) :
• Recueil des besoins
• Confirmation des besoins.
• Design - inclure à la fois Architecture et le design détaillé des étapes de
conception.
• La mise en œuvre.
• Test d'acceptation en usine.
• Installation, mise en service et intégration.
• Test d'acceptation du site.
• Préparation opérationnelle et transition. Handover (solution clé en main)
• Services d'exploitation et d'entretien.
La séquence des étapes, y compris la détermination des activités de la voie critique, doit
être définie dans le calendrier des travaux et sera soumise à l'approbation de L'ONDA.
Il sera possible d'entreprendre des étapes de développement parallèlement afin

d'accélérer les délais du projet. La transition entre les étapes de développement est
soumise à un processus d'examen et d'approbation de l'étape spécifique par l’ONDA.
La solution proposée (PI-ESB), qui sera par la suite intégrée dans cette architecture, fait déjà
partie du champ d’application du présent marché.
5.4. MODELE PI-ESB ET CAPACITE

La figure 1 ci - dessous illustre les différents composants de la PI-ESB. Toutes les solutions
proposées devront définir deux domaines clés :
• Cadre architectural de la solution proposée
• Conception des composants et mise en œuvre, en particulier Enterprise Service Bus
(ESB), Master Data Management (MDM), Aéroport Base de données opérationnelle
(AODB) et l'entreposage de données (DWH), Identity and Access Management /

SSO Portails (SAML), Consumer Communications (CC ) et Business Rules Engine (BRE)
Toutes les solutions proposées doivent être capables d'intégrer des applications construites sur
des plateformes hétérogènes
Cela inclut toutes les applications aéroportuaires individuelles et les systèmes qui doivent
être intégrés dans cette architecture et qui font partie du champ d’application du
présent marché.
Schéma 1 : PI-ESB Architecture
5.5. EXIGENCES DU CADRE PI-ESB

Ci-dessous la liste des éléments-cadres, des technologies et des services qui font partie
des opérations au sein de la PI-ESB. Les prix devront prendre en compte à la fois la
fourniture, installation et mise en service (Configuration et / Mise hors service) mais aussi
la mise à niveau et le support.
Cadre des Descriptions des services / technologies

Composants
Plateforme Organiser et faire des points d'intégration visibles et les processus
dÍntégration entre les systèmes internes et externes. Établir un répertoire des
- services techniques et commerciaux exposés par les différents
Enterprise Service composants et systèmes d'entreprise (c.-à-d. la gestion de l'API)
Bus (PIESB).
PI-ESB L'entrepreneur doit vérifier que les composants PI-ESB
composants et comprennent et / ou fournissent / soutiennent les exigences

fonctionnalités suivantes :
requises • Autonomie PI-ESB (non couplé)
• Gestion des API
• Système d'intégration
• Routage
• Messagerie
• Transformation
• Orchestration
• Un des Adaptateurs ou plus :
o IBM
o WebSphere o MQ
o ODBC
o Service Web (WS- *, REST, ODATA) o MS o SQL o
Oracle FTPS, SFTP, HTTPS
o MSMQ
• Système de fichiers
• Programmation déclarative
• Surveillance et gestion des pannes
SOAM et SSPM Garantie que l’intégration de ces applications d'entreprise

peut être intégré dans la PI-EBS.
• Base de données opérationnelle de l'aéroport (AODB) et
Data Warehouse (DW).
• Enterprise Service Bus / Middleware (ESB / MW / MW).
• Système de gestion des ressources (RMS).
• Système de gestion de vol, KPI et statistiques (FMS).
Solution de réconciliation bagages (BRS)
• Système d'affichage des informations de vol (FIDS)
• Équipement terminal à usage commun (CUTE/CUPPS) et
service de bornes à usage commun (CUSS) et bag drop.
Base de • Fournir et garantir la capacité d'intégration, d'analyse et de

données report des données, en plus de normaliser leurs processus de
opérationnelle stockage, de déplacement et d'accès. Le fournisseur doit
de lÁéroport veiller à ce que les composants de lÁODB satisfassent aux
(AODB) et Base exigences minimales suivantes
déntreposage :
de données • Doit avoir des composants d'intégration qui permettent la
(DWH) création standardisée de charge des transformations
d’extension (ETL) des procé dés, de mise en scène des
données transactionnelles des DataWarehouse les plus
couramment utilisés (SQL Server, Oracle, ERP, CRM,
mainframe, etc.).
• Doit inclure des outils pour créer et publier des rapports
standard de base et des tableaux de bord.
• Doit avoir une capacité éprouvée à se coordonner avec les
systèmes clés d'aéroport existants sans modifications
invasives, telles que les déclencheurs de base de données
ou les procédures stockées dans les systèmes tiers existants.
Le fournisseur doit indiquer des exemples d'intégration avec

les aéroports internationaux, le fournisseur de ces systèmes
d'aéroport tiers et les données échangées avec chacun
Doit fournir des dictionnaires de données pour le DWH.
Doit prendre en charge les requêtes SQL standard.
Doit décrire comment s’intégrer à AODB pour garantir

l’échange de données entre AODB, et la PIESB. Inclure dans
la description comment le système compte gérer les
exigences fonctionnelles et non fonctionnelles, y compris :
o Formats de données / modèles d'échange
(demande-réponse, publication-abonnement,
notification de changement de données en temps
réel) / traitement des exceptions
o Gestion du rendement
o Résilience, haute disponibilité des systèmes, des
services et des interfaces
o Contrôle et surveillance des systèmes, des services et
des composants
o Utilisation des normes (international le cas échéant)
o Sécurité / authentification, qui doit avoir un modèle
de sécurité complet, défini et documenté,
aborder la sécurité à tous les niveaux
Décrire en détail comment la solution accorde / refuse

l'accès aux services par les utilisateurs finaux ou les systèmes
clients. Aussi, décrire le support pour les protocoles sécurisés
(TLS / SSL) et sa mise en œuvre dans l'ensemble de
l'infrastructure, y compris les interactions avec les clients sur
différents protocoles de transport.
Gestion des Activer la sécurité, le partage des données inter organismes
identités et des avec des données de haute sécurité accessibles sous Single
accès / Portails Sign On (SSO) et Identity Access Solutions Management
SSO (SAML) (IAM) avec les exigences minimales suivantes :
Doit fournir l'audit des opérations IAM (quand / qui a

changé les informations sur le compte, etc.) et l'audit de
l'accès au système via IAM / SSO (quand était la dernière
fois que quelqu'un a accédé à des données dans system1,
etc.).
Doit être compatible avec SAML (v.2) (c'est-à-dire, doit être
facilement utilisable par l'une des plates-formes
d'application les plus utilisées : .NET, JAVA, PHP, etc.).
Doit inclure Active Directory (AD) / intégration LDAP (y
compris la synchronisation). Les services Active Directory se
composent de plusieurs services d'annuaire. Le plus connu
est Active Directory Domain Services, communément
abrégé en AD DS ou simplement AD
Doit fournir un compte d'utilisateur administratif (Help Desk
ou personnel agréé doit être en mesure de créer et gérer
des comptes d'utilisateurs pour les utilisateurs, le processus

d'approbation pour un nouvel enregistrement de
l'utilisateur, et hors des flux de travail d'embarquement).
• Doit gérer les administrateurs centralisés, peut créer des
rôles personnalisés et des permissions qui peuvent être
assignés aux utilisateurs désirables pour leur permettre
d'effectuer des tâches dans les limites administratives
spécifiées.
• Doit inclure un compte d'utilisateur / Gestion de mot de
passe / Self-service (les administrateurs / utilisateurs finaux
devraient pouvoir créer et modifier leurs comptes
d'utilisateurs, y compris les mots de passe).
• Doit avoir des fonctionnalités de contrôle d'accès /
autorisation (capacité à gérer les rôles / groupes en plus de
la gestion d'identité de base, une administration spécifique
limitée à l'application).
• Doit s'intégrer dans Active Directory pour les utilisateurs
internes (environ 5 000, mais évolutifs jusqu'à 50 000+).
Consumer Faciliter et uniformiser la distribution de la communication. Avec la

Communications fonction de livraison des communications envoyées en utilisant
(CC) tous les protocoles communs (courrier, e-mail ou SMS, etc.).
Composant CC avec les exigences minimales :
• Doit prendre en charge la composition de document de
communication interactive et déclarative (c.-à-d., Modèles
d'avis de longueur dynamique paramétrés, modèles de
courrier électronique ou notifications par SMS, etc.).
• Doit fournir un suivi fiable de bout en bout des
communications de la source à la cible.
Business Rules Améliorer la transparence et l'utilisation des règles commerciales

Engine (BRE) standards. Établir une ressource partagée pour les systèmes
nécessitant une BRE externalisée.
Bien que de nombreuses applications principales des systèmes et
plateformes aient déjà intégré ces règles, un certain nombre de
règles concernant les parties prenantes doivent être visible et
accessible à tous les systèmes au travers des applications.
Exigences • Tous les composants architecturaux doivent utiliser le logiciel
relatives aux COTS (Commercial-off-the-Shelf). Cependant, chaque
composants composant peut être considéré séparément de telle sorte
qu'il n'y ait aucune exigence à ce que tous les composants
soient un seul logiciel ou proviennent d'un fournisseur
unique, si cela s'applique.
• Tous les composants doivent pouvoir intégrer et utiliser le
composant Identity and Access Management / Single
Sign-On (IAM / SSO) pour l'authentification.
• Líntégration à des systèmes futurs doit pouvoir être réalisée
par lÓNDA et utiliser des interfaces ouvertes standards et
des protocoles non-propriétaires documentés. Par exemple,
SOA (architecture orientée service).
• Doit fournir une liste des services SOA proposés en standard
5.6. ENVIRONNEMENT PROJET – VOLUMES DE DONNEES ET ENVIRONNEMENT
1- La solution doit inclure une suite éprouvée de services de SOA spécifiques aux
aéroports existants. Une description détaillée de chaque service est requise, y
compris les sites de référence où les services sont utilisés. Un des sites de référence
doit avoir plus de 10 millions de passagers par an et plus de 200 mouvements
d'avion par jour et un des sites de référence doit être en configuration multi-
aéroports.
2- Estimations du nombre de message à titre indicatif :
a. ESB / PI /API : 500,000 invocations/jour et 400,000 messages d’intégration/
jour
b. AODB : plus de 25 millions de pax/an, 15,000 utilisateurs, 150,000 fournisseurs
c. DataWareHouse : plus de 25 millions de passagers/an, 15,000 utilisateurs et
150.000 fournisseurs avec toutes les entités liées à ces applications
(documents, cas, etc.), pour un total d'environ 10-15 TB de données
sur la plateforme d'intégration, les aéroports internationaux

où ces services sont utilisés, le fournisseur tiers utilisant ces
services et la durée pendant laquelle ils ont été utilisés pour
une utilisation opérationnelle complète.
d. Traitement de messages automatiques : environ 15,500 envois/jour, 6,000
courriels par jour, 9 000 SMS /jour, 500 fax / jour
e. Moteur de règles métier (BRE) : 3000 règles actives
3- La solution doit être mise en œuvre et prouvée dans les principaux aéroports
internationaux en configuration multi-aéroports ; la solution déployée doit avoir
une évolutivité éprouvée dans l'environnement de l'aéroport et avoir déployé
plus de 10 interfaces client unique sur la PI-ESB dans un seul aéroport. Donner des
détails sur les solutions déployées, le nombre et les types de services et de clients.
5.7. EXIGENCES D'HEBERGEMENT ET DE L’INFRASTRUCTURE

Le fournisseur peut fournir un des deux modèles d’hébergement en architecture
centralisée sur un site principal à l’aéroport de Casablanca et sur le site de backup :
• Un hébergement centralisé multi-aéroports en utilisant une solution

d’infrastructure intégrée et redondante sur un cloud privé (hyper-convergée),
combinant serveurs, stockage, et équipements réseaux incluant les logiciels
nécessaires à leur exploitation, une plateforme de virtualisation (type VMware,
Hyper V ou autre) et une couche d’administration unifiée.
• Un hébergement centralisé multi-aéroports en utilisant une solution

d’infrastructure classique avec des serveurs physiques redondants, des baies de
stockage redondantes, des Switchs SAN redondants, des Switchs réseaux
redondants au site principal central à l’aéroport de Casablanca et au niveau
du site de backup.
Le modèle proposé doit détailler la stratégie de transition de chaque composant.

Toutes les options doivent être détaillées par des exigences et
spécifications techniques.
• Structure de licence d'entreprise de logiciel

• Spécifications et exigences matérielles
• Conditions de base de données
• Type du système de virtualisation
• Exigences du système d'exploitation
• Exigences de réseautage (Bande passante, etc.)
• Exigences de configuration de sécurité
5.8. LIVRABLES
Les conditions suivantes doivent être fournies et / ou complétées par l'Entrepreneur
pendant le cours et la durée du contrat résultant de la présente Appel d’Offres :
• Plan de gestion du projet complet décrivant la conception, le développement et
la mise en œuvre des composants PI-ESB spécifiés et leur cadre. Cela doit aussi
inclure une assurance qualité / plan de gestion de la qualité, le
plan de communication du projet.
• plan de gestion des risques, la gestion des ressources et plan de gestion des
changements, y compris les plans de mise en œuvre le contrôle des
changements. Ceux-ci doivent être impérativement inclus dans le Plan de gestion
de projet complet.
• Tous les composants prêts à la production comprenant l'architecture d'entreprise.
Tous les composants spécifiés doivent être disponible dans tous les
environnements de gestion du cycle de vie des applications (ALM)
(développement, système Test d'intégration, test d'acceptation des utilisateurs,
formation et production).
• Cadre global PI-ESB et d'intégration système pour chaque composant de la
solution proposée. L'éditeur doit concevoir la gouvernance d'entreprise et
concevoir et établir des cadres techniques pour l'architecture d'entreprise
proposée. Les cadres serviront de seul point de référence pour le contrôle et la
gestion des actifs PI-ESB. Ce plan doit tenir en compte non seulement de la gestion
continue des changements, de la gestion des données et de la gestion
technique, mais aussi de la mise à niveau des logiciels et de la planification et des
stratégies en fin de vie.
• Répartition des coûts / processus de facturation pour chaque composante de la
PI-ESB pour permettre par facturation à l'usage pour chaque système utilisant la
PI-ESB.
• La méthodologie et le plan de gestion du cycle de vie des applications (ALM)
pour chaque composant Enterprise Architecture, prenant en charge au moins les
étapes / environnements suivants : o Développement
o Test d'intégration de système (SIT)
o Test d'acceptation des utilisateurs (UAT)
o Formation o Production
• Formation du personnel de l’ONDA sur tous les outils mis en place. Ceci doit inclure
un plan de formation très détaillé.
• Plans d'intégration du système pour toutes les applications et systèmes d'affaires,
en particulier les plans de transition et d'intégration des applications / systèmes
suivants
o Base de données opérationnelle de l'aéroport (AODB) et Data

Warehouse (DW).
o Système de gestion des ressources (RMS).
o Système de gestion de vol, statistique et mesure des KPI (FMS).
o Solution de réconciliation bagages (BRS) o
o Système d'affichage des informations de vol (FIDS)
o Équipement terminal à usage commun (CUTE) et service
autonome à usage commun (CUSS)
o Systèmes d'affichage d'informations de vol (FIDS) o
o Système de manutention des bagages (BHS) o
o Facturation aéronautique(Aviation)
o Systèmes de contrôle de la circulation aérienne (ATC) Et aussi
pour les systèmes suivants s’ils ont intégrés :
• La solution information PI-ESB doit permettre aux messages dont le contenu

(charge utile) à être corrélé et suivit comme ils traversent la PI-ESB, y compris via
une interface utilisateur conviviale et un utilisateur graphique pour visualiser et
analyser les données. La solution doit être en mesure de fournir un suivi des
messages en temps réel et une analyse historique des données des messages par
service SOA, par client. La solution doit fournir des rapports statistiques sur les flux
de messages, les exceptions de messages (par exemple supprimées, temporisées,
rejetées) dans l'ensemble du système. La solution doit fournir une piste d'audit de
toute action / commande d'utilisateur appliquée à la plateforme ou aux services.
Décrire en détail les installations et les opérations que la solution fournira.
6. SYSTEME RMS
1- Le système RMS est la plate-forme par laquelle les différentes ressources

aéroportuaires sont gérées, planifiées et allouées, telles que les portes
d'embarquement, les convoyeurs de bagages, les parkings d'avions, etc.
2- Le système RMS doit fournir les fonctionnalités nécessaires pour allouer des
ressources aux horaires de vol sur la base d'une ou de plusieurs règles qui
représentent le mode d'exploitation d'un aéroport.
3- Le système RMS doit être basé sur des solutions COTS et capable d’offrir une
adaptation minimale pour répondre aux besoins de lÓNDA.
4- Le système RMS doit fonctionner entièrement en temps réel avec les données de
gestion de vol/ AODB. la communication avec l’AODB s’effectuant en mode natif
ou a travers la plateforme d’integration.
5- La technologie à utiliser doit être de dernière génération, modulaire en matériel
et logiciel, afin de minimiser et d'isoler facilement les défaillances possibles.
6- L'équipement proposé doit être de marques de prestige reconnues, qui
présentent des niveaux élevés de fiabilité et de disponibilité. De même, il devrait
pouvoir fonctionner à capacité réduite sans dégradation du service et permettre
un accès à distance pour l'entretien ou la reconfiguration en usine si nécessaire.
7- La conception du système devrait comporter des facilités d'évolutivité pour

permettre la croissance du système, avec seulement l'agrégation matérielle et
logicielle.
8- Le système RMS devrait être installé dans les aérogares suivantes et utilisera
l'infrastructure de communication disponible dans le bâtiment de l'aérogare
passagers et entre les aeroports de lÓNDA.
Les aérports concernés sont :
Aéroport Code
Casablanca CMN
Marrakech RAK
Rabat RBA
Agadir AGA
Fès FEZ
Tanger TNG
Nador NDR
Oujda OUD
9- L'architecture du système RMS devrait permettre une définition centralisée des

utilisateurs et des rôles, avec la possibilité de configurer différents niveaux d'accès
aux applications et aux données.
10- Le système RMS doit être facilement évolutif et configurable, notamment dans le
cas d'un ajout ou d'une suppression de services (nouveaux écrans, nouveau type
d'information ou nouvelles sources de données à contrôler).
11- Il doit être possible de modifier la liste de ressources et leurs caractéristiques tout
en travaillant dans la planification et en temps réel, sans redémarrage de
l’application.
12- Le système RMS doit permettre de créer des scénarios « what if » en parallèle à
son opération.
6.1. SPÉCIFICATIONS FONCTIONNELLES
6.1.1. SPECIFICATIONS FONCTIONNELLES COMMUNES
1- Le système RMS sera configuré de manière à répondre aux exigences

opérationnelles et aux exigences de performance de plusieurs utilisateurs
connectés simultanément dans le système, sur 8 plateformes aeroportuaires
differentes.
2- Lárchitecture pourra etre soit centralisee, soit distribuee dans les 8 aeroports, et
léditeur devra justifier lárchitecture proposee. 3- Authentification et contrôle
d'accès
a. Le système devrait utiliser des mécanismes de connexion au serveur, au
poste de travail et à l'application par le biais d'un nom d'utilisateur et d'un
mot de passe.
b. Le système doit permettre à un administrateur système de restreindre

l'accès d'un utilisateur à tout composant du système.
c. Le système doit permettre l'authentification des utilisateurs et l'accès aux
ressources par le biais du LDAP et/ou de l'annuaire actif des aéroports.
d. Le système doit permettre la définition des rôles et/ou des profils associés
aux niveaux de sécurité et aux droits d'accès.
e. Le système devrait fournir des mécanismes de contrôle pour l'accès aux
données stockées dans la base de données, afin de permettre de créer,
interroger, mettre à jour, effacer les données et les tableaux en fonction
des profils des utilisateurs finaux et des techniciens.
f. Le système devrait prévoir la possibilité d'activer des mécanismes d'audit
pour les données et/ou les tableaux.
4- Fuseau horaire
a. Le système doit vous permettre d'utiliser les horaires UTC ou le fuseau horaire
local.
b. Le système doit utiliser le service NTP.
5- Interface utilisateur final
a. Le système devrait fournir une interface utilisateur final basée sur l'utilisation
de fenêtres conviviales.
b. Le système doit être multilingue (francais, espagnol, anglais et autres) et
permettre la configuration et la sélection de la langue francaise pour les
utilisateurs finaux.
c. Le système doit permettre l'utilisation de couleurs pour configurer les alertes
et les événements liés au vol
d. Le système doit permettre l'utilisation de filtres sur les écrans des différents
modules du système.
e. Le système doit utiliser et être compatible avec les codes IATA, OACI pour
les codes d'aéroport, pays, villes, compagnies aériennes, types d'aéronefs.
6.1.2. SPECIFICATIONS FONCTIONNELLES DU SYSTEME RMS
1- Gestion des ressources

a. Le système RMS devrait permettre une gestion simple et efficace des
ressources aéroportuaires grâce à un environnement graphique
comprenant l'affichage des graphiques de Gantt et l'allocation des
ressources par glisser-déposer.
b. La solution doit permettre de retrouver rapidement un vol dans une liste ou
un diagramme de Gantt, en utilisant tout élément décrivant ses
caractéristiques (origine, destination, type d'avion, immatriculation,
transporteur, prestataire d'assistance au sol, etc.)
c. La solution doit permettre de filtrer les diagrammes de Gantt pour n'afficher
que les ressources ayant certaines caractéristiques ainsi que certains types
d'affectations de vol. Par ex. les avions-cargos et les postes de
chargement, ou les avions internationaux et les mouvements
internationaux.
d. Les affichages Gantt doivent être entièrement continus sur plusieurs jours,
passage à l'heure d'été/ d'hiver compris
e. La solution doit permettre une affectation des ressources entièrement

manuelle, semi-automatique et entièrement automatique sur n'importe
quelle période et dans n'importe quel module RMS.
f. Le système doit être capable de recevoir les messages LDM et MVT et
d’afficher sur un tableau de bord les informations sous forme graphique.
g. Le système RMS devrait permettre à l'utilisateur de personnaliser
l'environnement de travail en utilisant différentes couleurs pour identifier les
opérations, par exemple en assignant une couleur spécifique à une
compagnie aérienne.
h. Toutes les données gérées par l'interface RMS doivent être stockées dans
la base de données AODB.
i. L'exploitant du système RMS doit être en mesure d'allouer/désaffecter des
ressources aux vols.
j. Le système doit pouvoir planifier des affectations commençant une
journée et se terminant les jours suivants.
k. Les ressources incluses dans le système de gestion des ressources devraient
être, au minimum:
i. Places de stationnement pour aéronefs.
ii. Portes d'embarquement et de débarquement. iii.
Carrousels bagages.
iv. Comptoirs d'enregistrement et/ou postes d'enregistrement (tables,
kiosques, zones)
v. Véhicules de remorquage d'aéronefs
vi. Autobus pour passagers et personnel de cabine.
l. Le système RMS doit permettre ce qui suit :
i. l'allocation/la répartition des ressources humaines, des
équipements et de l'infrastructure pour la gestion et l'exploitation de
l'aéroport.
ii. blocs de réservation de ressources.
iii. création de mouvements au sol des aéronefs
iv. visualisation de la planification des jours futurs, en saisissant les dates.
v. allocation automatique des ressources par l'utilisation de règles pre-
définies.
vi. accès à la messagerie IATA a travers la plateforme d integration. vii.
changement de programme d'une opération
m. Dans le cas où l'AODB n’a pas été en mesure d'allouer automatiquement
une ressource, le système RMS doit permettre la création de ressources
virtuelles clairement différenciées, pour lesquelles il laisse l'opération de vol
allouée sans ressource physique à l'exploitant pour qu'il procède
manuellement à l'allocation.
n. Le système RMS doit permettre l'allocation de ressources spécifiques. Par
exemple, une compagnie aérienne basée sur un modèle contractuel
unique.
o. Le système RMS doit etre capable de generer des scenarios pour permettre
le choix optimal a lóperateur
p. Le système RMS couple avec lÁODB doit être prêt pour fonctionner dans
un environement A-CDM
2- Planification, restrictions et gestion des conflits

a. Le système RMS devrait permettre de définir les règles et les priorités
associées à l'allocation des ressources. Par exemple, des règles impératives
qui doivent toujours être respectées ou des règles qui, par ordre de priorité
et/ou de score prédéfini, doivent être appliquées avant ou après d'autres.
b. La solution doit permettre de configurer entièrement le délai de séparation
standard entre deux affectations consécutives de la même ressource, en
tenant compte de toutes les caractéristiques connues des vols départ ou
arrivée.
c. Les tractages doivent être clairement identifiables dans le diagramme de
Gantt. Il doit être possible de modifier les tractages directement depuis le
diagramme de Gantt et d'entrer les heures prévues et réelles, au besoin.
d. Le système RMS doit permettre la définition des heures et des dates (début
et fin) pour les différentes règles définies.
e. Le système RMS doit permettre la déclaration des ressources non
opérationnelles ou indisponibles, en tenant compte d'une ressource
individuelle, par groupe de ressources et/ou période.
f. Le système RMS devrait permettre de définir les capacités maximales de
ressources à prendre en compte dans le processus d'allocation.
g. Le système de gestion des comptoirs d’enregistrement doit permettre de
gérer :
i. Le nombre de comptoirs alloués en fonction des caractéristiques
des vols gérés.
ii. Les enregistrements banalisés (Common checkin)
iii. Possibilité d'attribuer des comptoirs distincts à tout ou partie des vols
comprenant un partage de code ou un mouvement à vols
multiples
iv. Possibilité d’attribuer des comptoirs spécifiques à des classes de
passagers différentes
h. Le système RMS devrait permettre aux utilisateurs d'identifier et de créer
leurs propres restrictions et de définir les règles qui affectent ces limitations.
i. Le système RMS doit fournir des alertes automatiques en cas de conflit
d'affectation. Y compris les fonctions de résolution des conflits.
3- Simulation et gestion de scénarios
a. Le système RMS doit permettre la génération de scénarios permettant de
simuler la gestion des ressources.
b. Le système RMS doit disposer d'un outil de génération de scénarios, ou de
simulations, dont l'objectif est d'anticiper la disponibilité des ressources
aéroportuaires en fonction de certaines conditions simulées:
i. Nouvelles opérations ou arret dóperations.
ii. Changements dans les horaires iii. Travaux d'infrastructure
aéroportuaire affectant les ressources.
6.2. SPÉCIFICATIONS TECHNIQUES
1- Le système RMS doit être basé sur l'architecture client/serveur de dernière

génération.
2- Le système doit fonctionner en continu (7J/24H) dans l'environnement

aéroportuaire sans dégradation des performances.
7. SPECIFICATIONS DE LA PLATEFORME TECHNIQUES SUPPORTANT LES APPLICATIONS AODB,

RMS, LA PLATEFORME DÍNTEGRATION (PI-EBS)
7.1. GENERALITES
Les serveurs, les équipements de mise en réseau (pare-feu, commutateurs, etc.), les
unités de stockage, les unités de sauvegarde, les onduleurs et d'une manière générale,
tous les équipements situés dans les salles de serveurs au niveau du site principal et au
niveau du site de backup doivent :
1- Permettre le montage sur des racks standard (42 ou 47 RU, 19 " 600x1200 ou
800x1200mm) avec module KVM.
2- Disposer de la double alimentation électrique et les unités de ventilation doubles
doivent être accesibles et peuvent être remplacées sans perte de service.
3- Disposer dans chaque rack de 2 blocs multiprises au moins pour permettre le
raccordement à 2 alimentations de sources différentes.
4- Mettre en place un onduleur de capacité suffisante avec un tableau éléctrique
et des disjoncteurs d’isolements pour protéger tous ces équipements.
5- Disposer d'une double connectivité (interface réseau) séparée pour la mise en
réseau
6- Disposer d'une double connectivité (interface réseau) séparée pour les réseaux
LAN (10/100/1000 mbps) et/ou SAN, le cas échéant. Y compris les mécanismes
HA (bounding, team, powerpath, etc.), avec connexion à des commutateurs
redondants.
7- Disposer de commutateurs redondants qui relient tous ces équipements au
réseau LAN.
8- Disposer d'une carte de contrôleur d'accès à distance (Remote Access
Controller), qui permet la télémaintenance et le support non assisté.
9- Disposer d'une alarme sonore et d'une alarme visuelle avant ou arrière selon les
spécifications du fabricant.
10- Disposer de périphériques de support connectés via USB ou port RJ 45 en TCP/IP.
Pour ce qui concerne de la plateforme logicielle, elle doit avoir :
11- Support de la structure des répertoires tels que NTFS ou NTFS32 ou équivalent
12- Le système d'exploitation à utiliser sur la plate-forme doit être Windows, Linux 64
bits, capable de gérer plusieurs tâches et supérieur à la version n-2 en vigueur
dans l'industrie.
13- Le logiciel de base de données utilisé devrait:
a. Utiliser un standard SGBDR : ORACLE ou MS SQLSERVER
b. Assurer l'intégrité et la cohérence des données.
c. Disposer de mécanismes de haute disponibilité et de réplication des
transactions.
d. Assurer la saisie des transactions en temps réel.
e. Disposer d'outils de sauvegarde autonomes qui assurent des points de

cohérence dans le temps.
14- Supervision technique et exigences de maintenance
a. Le système doit être doté de mécanismes qui permettent le
déclenchement, la pause ou l'arrêt des services d'application et/ou de
base de données, y compris la génération d'alarmes basées sur l'état
actif/passif et/ou les dépassements de seuil.
b. Le système devrait fournir des capacités d'autodiagnostic pour tous les
composants situés dans les salles de serveurs, en générant des notifications
et/ou des alertes par le biais d'outils de messagerie électronique et/ou de
messagerie.
c. Le système doit comprendre des capacités de surveillance,
l'enregistrement des périodes d'indisponibilité du service et la mesure du
temps de disponibilité par l'utilisation du SNMP.
d. Le système devrait être en mesure de signaler les caractéristiques
techniques et les versions des serveurs, de l'équipement de réseautage, du
stockage de sauvegarde et des périphériques.
15- Exigences environnementales :

a. L'équipement sera conçu pour une utilisation intensive dans les conditions
climatiques suivantes :
i. Équipement logé à l'intérieur d'un bâtiment climatisé
Température jusqu' à + 30 ° C
Humidité 0 à 65% humidité
Pression minimale 700 mm Hg
16- Exigences logicielles :
a. Tous les logiciels d'application, y compris les licences, nécessaires au bon

fonctionnement du système et les autres logiciels de (supervision,
protection antivirale, …etc) avec support logiciel.
b. Tous les logiciels de la base de données (Oracle ou SQL Server), y compris

leurs licences, nécessaires au bon fonctionnement du système avec
support logiciel.
c. Mode de licence perpétuelle, pour les logiciels d'application.
7.2. PLATEFORME MATERIELLE :

8. ETAPES DE LA MISE EN PLACE DU SOAM
9. PRESENTATION DE L’OFFRE :
10. DOCUMENTATIONS

AO Mise en Place SOAM

Transféré par

Droits d'auteur :

Formats disponibles

AO Mise en Place SOAM

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AO Mise en Place SOAM

Transféré par

Droits d'auteur :

Formats disponibles

Règlement de Consultation 207/18/AOO

Règlement de Consultation 207/18/AOO

DOSSIER D’APPEL D’OFFRES

Appel d’offres ouvert N° 207/18/AOO

Fourniture, installation, mise en service et maintenance d’un

 Tranche ferme : Fourniture, installation, mise en service et

1 Fourniture de la Partie matérielle de la plateforme Ensemble 1

2 Fourniture de la Partie logicielle du SOAM (AODB, Ensemble 1

3 Fourniture de la Partie logicielle du SOAM (AODB, Ensemble 1

4 Fourniture de la Partie logicielle du SOAM (AODB, Ensemble 1

5 Fourniture de la Partie matérielle (postes Opérateurs Ensemble 1

6 Fourniture de la Partie matérielle (postes Opérateurs Ensemble 1

7 Fourniture de la Partie matérielle (postes Opérateurs Ensemble 1

8 Conception, paramétrage, interfaçage, intégration Forfait 1

9 Conception, paramétrage, interfaçage et Forfait 1

10 Conception, paramétrage, interfaçage et Forfait 1

TOTAL HORS TVA Y COMPRIS DROITS DE DOUANES (A)

DONT MONTANT DROITS DE DOUANE

TVA 20% (B)

TOTAL TVA COMPRISE (A+B)

CAHIER DES PRESCRIPTIONS SPECIALES

Appel d’offres ouvert N° 207/18/AOO

Fourniture, installation, mise en service et maintenance

 Tranche ferme : Fourniture, installation et mise en service d’un

Table des matières

CHAPITRE 2 : CLAUSES TECHNIQUES – Tranche ferme -

ARTICLE 06 : DELAI D’EXECUTION

Phase Mission Durée

Phase 1 Installation, paramétrage, 12 mois à compter date de l’ordre de

Phase 2 Installation, paramétrage, 4 mois à compter date de l’ordre de

Phase 3 Installation, paramétrage, 2 mois à compter date de l’ordre de

La Phase 2 et la Phase 3 peuvent être menées simultanément.

Chaque phase du projet fera l’objet d’un ordre de service partiel.

ARTICLE 16 : DESCRIPTION DU PROJET

• Aider à gérer la croissance de l´ONDA en améliorant les conditions de traitement des

FES 8 310 1 116 095

L´ONDA désire implémenter les nouveaux systèmes et processus en trois phases. La

Actuellement, le système d’information de gestion aéroportuaire de l´ONDA contient les

Un système d’information aéroportuaire (SIA) formé d’un module de gestion de vol

Les systèmes suivants font partis du SOAM à mettre en place :

- AODB (Airport Operational Database)

Le Système d´Operations Aéroportuaires Multiplateformes (SOAM) comprendra une

2.1. SYSTEME D´INFORMATION DE VOL

L´intention de l´ONDA est de mettre en place une AODB et de conserver AIRVISION

2.2. SYSTEME DE FACTURATION

Le système de traitement de données qui permet de générer la facturation baptisé

Le marché est constitué de Trois parties :

• Partie 2 : Implémentation d’un SOAM (AODB, plateforme d’intégration PI-ESB et

o Mise en qualité et reprise des données de référence o Intégrations aux autres

• Partie 3 : Implémentation d’un SOAM (AODB et plateforme d’intégration PI-ESB)

La partie 2 et la Partie 3 peuvent être menées simultanément.

4. BASE DE DONNEES OPERATIONNELLE AEROPORTUAIRE (AIRPORT OPERATIONAL DATA

La plateforme d´intégration (PI-ESB) assure la communication entre les applications

La technologie à utiliser doit être à la fine pointe de la technologie, modulaire en matériel et

La conception du système devrait comporter des facilités d'évolutivité pour permettre la

L'architecture de l’AODB et la plateforme d´intégration (PI-ESB) devrait permettre la

L'AODB et la plateforme d´intégration (PI-ESB) devraient être facilement extensibles et

4.1. SPÉCIFICATIONS FONCTIONNELLES DE L’AODB ET PI-ESB

4.1.1. AUTHENTIFICATION ET CONTROLE D'ACCES

a. Le système devrait utiliser des mécanismes de connexion au serveur, au poste