Pour les systèmes urbains, on dessine d’abord l’architecture, on parle équipements ensuite.
Le livrable de ce plan est un système intelligent urbain qui peut se construire par étapes, changer de fournisseur et être exploité durablement : le centre d’opérations intelligent voit la situation de toute la ville, la couche plateforme gère données et interfaces, et transports, sécurité publique, urgences et services municipaux montent en service projet par projet.
Quatre pièges fréquents des projets urbains
La plupart des problèmes ne sont pas techniques, mais dans la structure des achats.
Chaque département achète le sien
Transports, urgences et services municipaux construisent chacun leur plateforme ; les données ne communiquent pas, et le centre de commandement finit avec un grand écran, rien de plus.
Verrouillé par un seul fabricant
Interfaces non publiques, données inexportables : changer de fournisseur à la deuxième étape revient à tout recommencer.
Une liste d’équipements que personne ne filtre
Caméras et équipements réseau ont des origines complexes ; les problèmes de conformité de la chaîne d’approvisionnement ne se découvrent qu’après l’appel d’offres.
Construit, puis plus personne pour exploiter
La réception est le sommet : gardes, revérifications et mises à niveau n’ont pas de ligne budgétaire, et le système vieillit en deux ans.
Composition de l’architecture
Un centre, une plateforme, N applications. Chaque couche est réceptionnée séparément.
Centre d’opérations intelligent (IOC)
Accroché au noyau situationnel, il assure la situation de toute la ville, la diffusion des événements et le commandement d’urgence. Ce que voient les opérateurs de garde, ce sont des événements à traiter et leurs preuves — pas un grand écran assemblé de pièces rapportées.
- Agrégation et diffusion des événements de toute la ville
- Carte de situation et preuves sur le même écran
- Processus de commandement et de dispatching d’urgence
- Gardes et passations tracées de bout en bout
Couche plateforme urbaine
Identité unifiée, catalogue de données, normes d’API et bus de messages ; les systèmes départementaux se connectent selon la norme, et les nouvelles applications ne reconstruisent plus de socle.
- Identité unifiée et autorisations de poste
- Catalogue de données et définitions statistiques
- Normes d’API et bus de messages
- Normes de connexion des départements et critères de réception
Module de jumeau numérique
Les installations, le réseau routier et les événements sont cartographiés en un modèle urbain interrogeable : d’abord au service du dispatching et des exercices, ensuite étendu à la planification.
- Modélisation des installations et du réseau routier
- Cartographie et interrogation des événements
- Dispatching et exercices d’abord
- Applications de planification ensuite
Groupe d’applications de scénario
Signalisation et événements de transport, perception de sécurité publique, dispatching des ressources d’urgence et tickets des services municipaux, projet par projet, chacun avec ses propres critères de réception.
- Signalisation routière et traitement des événements de transport
- Perception de sécurité publique
- Dispatching des ressources d’urgence
- Tickets des services municipaux
Liste des modules commandables séparément
L’ensemble est une architecture ; la commande se fait par module : chacun peut être signé et réceptionné séparément, et ceux achetés plus tard se connectent à la même couche plateforme.
| Module | Ce qui est inclus | Produit de réception séparé |
|---|---|---|
| Centre d’opérations intelligent (IOC) | Agrégation et diffusion des événements, carte de situation et preuves sur le même écran, processus de commandement et de dispatching, traces des gardes et passations | Procès-verbal de réception de la mise en service de l’IOC et règlement de garde |
| Couche plateforme urbaine | Identité unifiée et autorisations de poste, catalogue de données, normes d’API et bus de messages, normes de connexion des départements | Dossier des normes d’interface et registres de réception des connexions |
| Module de jumeau numérique | Modélisation des installations et du réseau routier, cartographie et interrogation des événements — d’abord au service du dispatching et des exercices | Liste des modèles et registres de réception des interrogations |
| Pack scénario Transports | Coordination de la signalisation routière et processus de traitement des événements de transport | Procès-verbal de réception du scénario et exemples de traces de traitement |
| Pack Dispatching des ressources d’urgence | Registre des ressources d’urgence, processus de dispatching et soutien aux exercices | Règlement de dispatching et registres d’exercices |
| Pack Tickets des services municipaux | Réception, attribution, clôture et retour de visite des tickets municipaux | Procès-verbal de réception du processus de tickets |
| Pack Gouvernance et export des données | Dictionnaire de données, définitions statistiques et vérification d’export — la garantie de pouvoir tout emporter en changeant de fournisseur | Dictionnaire de données et registres de vérification d’export |
Comment la plateforme se connecte
Les projets urbains réutilisent les socles de toute la gamme ; on ne repart pas de zéro.
Noyau situationnel
Les événements, entités et chronologies de l’IOC proviennent du noyau unifié ; les produits de renseignement et d’alerte peuvent fournir directement.
KINGAI ID, édition institutions
Départements, postes et opérateurs ont des autorisations cloisonnées ; l’entrée des services aux citoyens et l’espace de travail interne sont séparés.
Socle d’exploitation ONE
Après la mise en service, surveillance, traitement et revérification sont exploités avec traces ; le client municipal reçoit les registres d’exploitation chaque mois.
Chemin de livraison
Les frais de conception peuvent faire l’objet d’une commande séparée, ou être imputés sur la mise en œuvre ultérieure. Chaque étape laisse un produit livrable réceptionnable.
Étude de l’existant
Inventorier les systèmes, données et listes d’équipements existants ; le filtrage de conformité se fait en parallèle.
Livrable : rapport d’inventaire de l’existant (listes des systèmes, des données et des équipements, conclusions du filtrage de conformité).
Conception générale
Architecture, normes d’interface, gouvernance des données, liste des étapes et référentiel d’exploitation et de maintenance sont validés en une fois.
Livrable : dossier de conception générale (architecture, normes d’interface, gouvernance des données, liste des étapes, référentiel d’exploitation).
Mise en œuvre par étapes
Construction et réception application par application ; chaque étape livre dictionnaire de données et vérification d’export.
Livrable : pour chaque étape, l’application elle-même, le dictionnaire de données, le registre de vérification d’export et le procès-verbal de réception.
Exploitation gérée
Les processus de garde de l’IOC, les revérifications et les mises à niveau entrent en exploitation durable ; les points de remplaçabilité des fournisseurs sont revus chaque année.
Livrable : rapport mensuel d’exploitation, registres de revérification, tableau annuel de revue des points de remplaçabilité des fournisseurs.
- Le plan de conception peut s’acheter séparément, sans être lié à la mise en œuvre ; la mise en œuvre se signe par étape, l’exploitation par année.
- Le plan embarque un trio de localisation : partenaire local, déploiement local, sources de contenu locales.
- Les projets urbains à l’étranger entrent par la chaîne d’approvisionnement d’un intégrateur général ou d’un partenaire local, et passent, commande par commande, l’évaluation d’exportation et du droit local.
Cadre d’ouverture et de conformité
Un système urbain court dix ans ; le contrat doit penser à la dixième année.
Clauses anti-verrouillage
API ouvertes, export des données et assistance à la sortie sont inscrits au contrat ; l’appel d’offres de la deuxième étape n’est pas pris en otage par la première.
Équipements filtrés
Équipements et composants passent, élément par élément, le filtrage de la Section 889, avec traces ; la diligence sur l’actionnariat couvre les fournisseurs sensibles.
Résidence des données
Les données de la ville résident selon la juridiction ; le déploiement peut être local ou sur réseau dédié, et l’organisation des clés est validée dès la phase de conception.
Limitation d’usage inscrite au contrat
La conception des applications de sécurité publique ne comprend ni génération de gabarits de reconnaissance faciale, ni fonction de surveillance individuelle de masse ; la limitation d’usage est écrite dans le contrat.
Questions fréquentes
Comment les systèmes départementaux existants s’y connectent-ils ?
Ils se connectent selon les normes de la couche plateforme, sans remise à zéro. La couche plateforme fixe d’abord l’identité unifiée, le catalogue de données et les normes d’API ; les systèmes départementaux se raccordent un par un, et les nouvelles applications se construisent directement sur la norme, sans reconstruire chacune leur socle.
Comment découper les étapes sans gaspiller ?
D’abord la couche plateforme et l’IOC, ensuite les applications de scénario, projet par projet. Chaque étape est réceptionnée séparément, avec dictionnaire de données et vérification d’export ; les résultats de l’étape précédente ne sont pas renversés par la suivante, et la liste des étapes est validée en une fois dès la phase de conception générale.
Qui produit le rapport de filtrage des équipements ?
La conclusion du filtrage est écrite dans le rapport d’inventaire de l’existant. Équipements et composants sont comparés élément par élément au filtrage de la Section 889, avec traces ; pour les fournisseurs sensibles, une diligence supplémentaire perce la structure de l’actionnariat, et la conclusion est livrée avec le rapport d’inventaire.
Qui assure les gardes de l’IOC ?
Les deux sont possibles ; c’est fixé dans le référentiel d’exploitation. La garde peut être assurée par l’équipe de la ville, gérée par nos soins, ou en roulement mixte ; dans tous les cas, traitements et passations sont tracés de bout en bout, et les registres d’exploitation sont soumis chaque mois.
À qui appartiennent les données, au juste ?
Les données de la ville appartiennent à la ville, avec résidence selon la juridiction. Le déploiement peut être local ou sur réseau dédié ; l’organisation des clés est validée dès la phase de conception, et export des données comme assistance à la sortie sont inscrits au contrat.
Peut-on n’acheter que la conception ?
Oui : la conception peut faire l’objet d’une commande séparée, sans être liée à la mise en œuvre. La mise en œuvre se signe par étape, l’exploitation par année ; l’imputation des frais de conception sur la mise en œuvre ultérieure est écrite dans le contrat de conception.
Et ensuite, quel bloc regarder
Confiance et conformité
Formes de déploiement, souveraineté des données, exploitation de sécurité, filtrage de la chaîne d’approvisionnement et limites d’usage, écrits au même endroit.
Noyau de renseignement et de situation
La situation de l’IOC vient du réseau de renseignement de sources publiques : voyez d’abord comment les données s’organisent.
Alerte aux catastrophes et de sécurité publique
L’urgence est le premier scénario à forte fréquence de l’IOC : commencez par connecter l’alerte.
Commencez par un inventaire de l’existant
Fournissez la taille de la ville, la liste des systèmes existants et les deux scénarios que vous voulez régler en premier : nous revenons d’abord avec un projet d’architecture et le référentiel des étapes.
