Image Alt

IPMI : institut professionnel des métiers de l'informatique

  /  Non classé   /  AMOA et cahier des charges pour la gestion des foules

AMOA et cahier des charges pour la gestion des foules

Mathieu Sbai · AMOA · Gestion des foules

Transformer les risques d’une foule en exigences de projet

Dans un projet consacré à la gestion des foules, l’AMOA doit convertir des enjeux humains et opérationnels en besoins compréhensibles par les architectes, les développeurs et les responsables de sécurité.

Grande foule réunie pendant un événement
Une foule doit être étudiée comme un ensemble de déplacements, de contraintes et de besoins d’information.
01 — Une fonction d’interface

L’AMOA traduit la réalité du terrain

Les responsables de sécurité décrivent des situations opérationnelles. Les équipes informatiques ont besoin d’exigences précises. L’AMOA construit le lien entre ces deux langages.

Le langage du terrain

« Nous devons repérer une accumulation avant que la pression ne devienne dangereuse. »

« Les opérateurs doivent continuer à travailler si une caméra tombe en panne. »

Rôle
AMOA

Le langage fonctionnel

Mesurer la densité par zone, suivre son évolution et déclencher une alerte selon des règles validées.

Prévoir plusieurs sources de données ainsi qu’un mode de fonctionnement dégradé.

02 — Recueil des besoins

Quelles questions l’AMOA doit-elle poser ?

01

Quelles zones surveiller ?

Entrées, sorties, escaliers, quais, tunnels, intersections et espaces proches des attractions.

02

Quels indicateurs utiliser ?

Densité, vitesse, direction, durée d’attente et évolution des concentrations.

03

Qui reçoit l’alerte ?

Chaque signal doit être transmis à une personne disposant d’une responsabilité clairement définie.

04

Quelle action déclencher ?

Ralentir les admissions, ouvrir une dérivation ou informer les équipes présentes sur le terrain.

05

Comment vérifier le résultat ?

Le système doit montrer si la densité diminue après l’intervention.

06

Quel mode dégradé prévoir ?

Les opérations doivent pouvoir continuer en cas de panne du réseau ou d’un capteur.

03 — Exemple fonctionnel

Rédiger un besoin testable

Exigence utilisateur
« En tant qu’opérateur du centre de contrôle, je souhaite être alerté lorsqu’une zone présente une augmentation persistante de densité, afin de vérifier la situation avant qu’elle ne devienne critique. »
  • L’alerte indique la zone concernée.
  • L’heure de détection est enregistrée.
  • L’opérateur peut consulter la source de l’alerte.
  • Une vérification humaine peut être demandée.
  • L’alerte peut être qualifiée ou clôturée.
  • Les actions réalisées sont conservées dans un journal.

Les seuils ne doivent pas être inventés par le logiciel

Ils doivent être définis par les responsables compétents à partir du lieu, du public, de la réglementation et des études de sécurité. L’AMOA formalise ces règles, mais ne remplace pas les autorités ni les spécialistes de la sécurité.

Équipe préparant les exigences d’un projet sur un tableau
Les ateliers permettent de confronter les contraintes du terrain, les attentes des utilisateurs et la faisabilité technique.
04 — Répartition des rôles

Qui intervient dans le projet ?

Acteur Responsabilité Contribution au projet
Maîtrise d’ouvrage Définit les objectifs et valide les décisions. Exprime la valeur attendue et les priorités.
AMOA Structure les besoins et coordonne les échanges. Rédige les exigences et prépare la validation.
Responsable sécurité Définit les règles opérationnelles. Valide les scénarios, seuils et procédures.
Business Analyst Analyse les processus et les règles détaillées. Formalise les parcours et critères d’acceptation.
Équipe technique Conçoit et développe la solution. Évalue la faisabilité et met en œuvre les fonctions.
Opérateurs Utilisent le système pendant l’événement. Testent l’outil et apportent leur expérience du terrain.
Le regard du consultant

L’avis de Mathieu Sbai

D’après le contenu transmis, Mathieu Sbai considère que l’AMOA doit rendre les besoins et les attentes parfaitement explicites. Cette exigence devient particulièrement importante dans un projet de gestion des foules, où une ambiguïté peut affecter la qualité de la surveillance ou la rapidité d’une intervention.

Son approche met en avant une communication permanente avec le client, une collaboration étroite avec les équipes de développement et un contrôle rigoureux de la conformité du résultat final.

Synthèse éditoriale fondée sur le contenu fourni. Elle ne constitue pas une citation directe de Mathieu Sbai.

Conclusion

Un bon système commence par un besoin bien défini

La technologie ne peut pas corriger seule un objectif mal formulé. Dans un projet de gestion des foules, l’AMOA aide les responsables à préciser ce qui doit être observé, qui doit être alerté et quelles actions doivent rester possibles.

Ce travail permet aux équipes techniques de développer une solution plus utile, plus testable et mieux intégrée aux procédures humaines.

Post a Comment