Lorsque la circulation routière de la ville se dégrade

Après vous avoir présenté Horus — le moteur d'intelligence routière qui évalue le danger à l'échelle d'une ville, redirige les conducteurs autour des menaces, et évacue les utilisateurs quand les urgences atteignent leur paroxysme, je vous annonce aujourd'hui que l'API Horus est enfin disponible

Équipe TraficDay

Abidjan déplace 5 millions de personnes par jour dans une ville conçue pour bien moins. Les inondations coupent les routes sans prévenir. Les manifestations s'enflamment en quelques minutes. Les accidents se succèdent aux heures de pointe. La question n'est pas de savoir si quelque chose se passe — c'est de savoir si les personnes concernées le savent à temps.

TraficDay a été conçu pour répondre à cette question. Et au cœur du système se trouve Horus — le moteur d'intelligence sur les risques routiers en temps réel, nommé d'après le dieu égyptien du ciel vigilant. Horus fait trois choses : il lit la ville, il évalue le danger, et quand le danger est à son paroxysme, il aide les gens à évacuer en proposant des itinéraires sûrs.

Voici comment ça fonctionne.

Une ville n'est pas une carte. C'est un signal.

La plupart des applications de trafic vous montrent à quoi ressemblent les routes. Horus pose une question différente : qu'est-ce que la ville nous dit en ce moment ?

Quand des utilisateurs signalent une inondation, un accident, une route barrée ou une manifestation, ces signalements ne vont pas directement sur une épingle de carte. Ils alimentent un modèle de menace mis à jour en continu. Chaque obstacle est pondéré par type, confirmé par plusieurs signalements indépendants avant d'être pris en compte, et progressivement effacé avec le temps. La ville devient un score vivant — un nombre entre 0 et 100 qui répond à une seule question : À quel point cet itinéraire ou cette route est sûr?

types d'obstacles suivis

360°

scan d'exfiltration au niveau Horus 1

30s

intervalle de vérification de reroutage

~500m

rayon de détection des doublons

Le score se traduit en un niveau de type DEFCON — trois états, où 1 est le plus critique. Mais le score seul ne suffit pas. Un accident grave isolé près d'un hôpital ne devrait pas mettre toute une ville en état d'alerte. Horus ajoute donc un second filtre : les niveaux élevés exigent des menaces réparties dans des zones géographiques distinctes. Un incident localisé reste local. Seul un schéma à l'échelle de la ville déclenche une alerte à l'échelle de la ville.

Niveau	Nom	Signification
1	Danger	Il est recommandé de ne pas sortir - circulation interdite.
2	Vigilance	Évitez les zones signalées- circulation fortement pertubée.
3	Attention requise	Restez vigilant. circulation perturbée.

Deux piliers, un seul système

Horus repose sur une séparation délibérée : un signal à l'échelle de la ville et une réaction au niveau de chaque utilisateur. Ni l'un ni l'autre n'est utile sans l'autre.

Pilier 1 — Signal

Horus-emergency

« Y a-t-il une urgence dans cette ville, et à quel point est-elle grave ? »

Ingère en continu les menaces confirmées dans une ville. Calcule un score de danger. Le traduit en niveau. Diffuse à tous les utilisateurs et partenaires dans la zone concernée.

Pilier 2 — Réaction

Horus-aware

« Compte tenu de la situation, que doit faire cet utilisateur maintenant ? »

Lit le signal d'urgence. Détecte les dangers sur les trajets actifs. Propose des itinéraires plus sûrs. Resserre les seuils au fur et à mesure que le niveau monte. Évacue les utilisateurs au niveau 1.

La relation entre les deux est asymétrique. Horus-aware fonctionne avec ou sans urgence active — les alertes de proximité et le reroutage sont toujours actifs. Mais à mesure que le signal monte, la réaction se durcit. Au niveau 1, le système propose une exfiltration en proposant des itinéraires sûrs. Le signal pilote la réaction.

Le niveau d'urgence ne se contente pas d'informer les utilisateurs de ce qui se passe. Il reconfigure en temps réel la façon dont le moteur de navigation traite le risque.

— Principe de conception Horus

L'humain dans la boucle — par conception

C'est là que Horus fait quelque chose que la plupart des systèmes automatisés ne font pas : il s'arrête avant l'action la plus décisive et attend un humain.

L'algorithme tourne en continu. Il calcule un niveau. Il écrit une suggestion dans le système. Mais ce n'est pas cette suggestion que les utilisateurs voient. Ce qui est diffusé sur chaque téléphone dans une ville, c'est le niveau déployé explicitement.

Garde-fou humain dans la boucle

L'algorithme suggère. Un humain déploie. Une diffusion d'urgence qui dit à des milliers de personnes de rester chez elles ou d'évacuer ne peut pas se déclencher automatiquement sur un simple seuil de score — cela exige un jugement, du contexte, et une responsabilité qu'aucune fonction de scoring ne peut assumer seule.

C'est un choix d'architecture délibéré, pas une limitation. Les faux positifs dans un système d'urgence ne gaspillent pas seulement l'attention — ils érodent la confiance qui rend les vraies alertes efficaces. Le filtre humain est le dernier contrôle avant que le signal devienne une action.

Niveau 1 : quand Horus vous évacue

Au niveau de menace le plus élevé, quelque chose change. Horus-aware cesse de proposer des itinéraires alternatifs dans la ville et pose une question différente : comment vous sortir entièrement du danger ?

Pour tout utilisateur en train de naviguer quand une urgence de niveau 1 est déclarée, Horus déclenche un scan d'exfiltration à 360°. Le système ne choisit pas une direction — il les cherche toutes.

Proposer des itinéraires

Sur un rayon précis dans toutes les directions avec une couverture totale et sans filtre initial.

Ajouter l'origine du trajet comme point de retour

Si le point de départ est classé comme sûr, faire demi-tour devient une option aux côtés d'aller de l'avant.

Évaluer chaque itinéraire, chaque route pour la sécurité

Chaque route proposée est évaluée face à la carte de dangers en temps réel. Les routes qui traversent des zones de danger connues sont pénalisées. Les routes sont classées par score de sécurité.

Proposer l'itinéraire de sortie le plus sûr — ou se mettre à l'abri

L'itinéraire le plus sûr est proposé àl'utilisateur. Si aucune route sûre n'existe dans aucune direction, Horus recommande de se mettre à l'abri plutôt que d'offrir un faux espoir.

L'utilisateur voit une animation de balayage radar pendant le scan — un visuel qui communique « le système cherche activement une sortie » sans créer de problème sur la vitesse. Le scan se termine en quelques secondes. Le choix reste au conducteur.

Conçu pour évoluer

Pour les partenaires — plateformes de VTC, entreprises logistiques, gestionnaires de flottes — Horus API est également disponible avec une interface REST qui expose les deux piliers via des webhooks signés et un modèle d'authentification standard par clé. Un partenaire enregistre ses trajets actifs, reçoit des événements de danger et des propositions de reroutage en temps réel, et relaie les décisions des usagers au système.

Construisez avec Horus

Horus API est ouvert aux partenaires. Commencez par le portail développeur ou consultez la référence technique.

Portail développeur Référence API

📧 Restez informé

Commentaires (0)

Laisser un commentaire

Abonnement requis