Principes directeurs d'architecture ()
Principes directeurs d'architecture
Lien
Les principes directeurs d'architecture de MeC
Principe 15 Standards de gestion opérationnelle des solutions
Principe 9 Identification, évaluation et atténuation des risques
Principe 3 Neutralité technologique
Principe 2 Architecture intégrée, modulaire et réutilisable
Principe 1 Primauté des principes d’architecture
Principe 10 Accessibilité et convivialité
Principe 11 Acceptabilité sociale et utilisation des données éthique et responsable
Principe 12 Conformité législative
Principe 13 Inclusion numérique
Principe 14 Écoconception des services et produits
Principe 7 Identité numérique commune
Principe 8 Sécurité optimale
Principe 4 Logiciels et matériels libres
Principe 5 Les données sont un bien précieux partageable
Principe 6 Standardisation
Etablir une architecture de solution intégrée, adaptable et évolutive
INFC
Optimiser l'allocation et la rentabilité du financement
Une seule ville bénéficie du financement
Les engagements sont limités à la durée du financement
Certains citoyens n'ont pas accès aux services
Réplicabilité
Pérennisation
Services Accessibles
Ville de Montréal
Livrer la vision gagnante du défi
Les personnes vulnérables ont accès à des service de piètre qualité
Économie du quartier sous-valorisée
Données numériques abandantes sous-exploitées
Mutualisation
Diminuer la fracture technologique
Offrir des services faciles à évoluer
Données ouvertes
Données numériques non accessibles
Diminuer le menottage technologique
Favoriser le partage d'experiences
Manque de clarté des besoins et leurs pertinences
Approche expérimentale
Assuer l'accès aux données pour offrir des services de qualité
Respecter la charte des données numériques de la ville
Une dépendence croissante des plateformes numériques
Services numériques
Assurer la continuité et la robustesse
Il est temps d'agir contre le changement climatique
Écoconception
Réduire l'empreinte écologique
Équipements et locaux sous utilisés
Exigence N 3.1 Faible couplage avec les dépendances et identification des alternatives
Exigence N 3.2 Possibilité de plateformes variées de déploiement
Exigence N 3.3 Il existe des plans de migration entre les alternatives technologiques
Exigence E 14.3 Les services offerts respectent une transition écologique
Exigence E 14.2 Les guides opérationnelles favorisent le choix des solutions et produits conformes au principe d'écoconception
Exigence E 14.1 Les services et produits sont offerts selon une vision stratégique d'écoconception
Exigence P 1.1 Les principes directeurs d'architecture sont communiqués aux équipes de réalisation internes/externes
Exigence P 1.2 Le choix des composants de solutions est validé pour assurer la conformité avec les principes directeurs
Exigence P 1.3 Toutes les divergences des principes directeurs sont documentées, justifiées et communiquées au comité TI
Exigence P 1.4 L'analyse de conformité avec les principes directeurs est maintenue à jour. Cette analyse est révisée par exemple avec tout changement significatif aux services
Exigence P 1.5 L'analyse de conformité avec les principes directeurs est un livrable requis avec chaque livraison de services dans le cadre du programme MeC
Exigence M 2.1 La documentation de l'architecture des services et systèmes est disponible et accessible. Fonctionnelle, applicative, données, technologique
Exigence M 2.2 Les services exposent des interfaces APIs disponibles aux parties tierces sans restrictions ou conditions sur le type des applications clientes.
Exigence M 2.3 Un inventaire d'APIs est disponible, documenté et accessible. L’inventaire des API est mis à jour et intégré dans l'inventaire des APIs du programme MeC.
Exigence M 2.4 L'architecture est modulaire. Il existe un référentiel de modules réutilisables à la disposition des équipes de réalisation internes ou externes. Le référentiel est intégré dans le référentiel des modules du programme MeC.
Exigence M 2.5 Un système doit être modulaire permettant d'activer / désactiver des fonctionnalités sans interruption des services du système entier.
Exigence M 2.6 L'architecture de la solution prévoit un processus automatisé de déploiement et de passage à l’échelle
Exigence M 2.7 L'architecture respecte le faible couplage des services
Exigence M 2.8 L'architecture de la solution et la conception des services respectent le libre flux de données
Exigence M 2.9 La documentation de l'architecture contient la gouvernance et la sécurité au niveau des services
Exigence M 2.10 La documentation de l'architecture identifie le composants critiques au fonctionnement du système
Exigence M 2.11 L'architecture prévoit des coupes-feu d’échec et des relèves au niveau des services
Exigence O 4.1 Distribution sous licence(s) libre(s). A noter que les licences plus permissives sont recommandées et la ville de Montréal a choisi MIT pour ses projets de licences libre.
Exigence O 4.2 Une copie de la ou les licences libres des contributions est partagé avec le comité TI
Exigence O 4.3 Les contributions sont-elles aussi disponibles sous des licences commerciales? Approbation requise le cas échéant.
Exigence O 4.4 Documentation et publication du modèle d’affaire
Exigence O 4.5 Dresser une liste des composants et module libres utilisés avec leurs licences.
Exigence O 4.6 Le code est disponible. Fournir le lien vers l’entrepôt du code.
Exigence O 4.7 L’entrepôt du code est conforme aux exigences minimales du dépôt libre (Annexe III)
Exigence O 4.8 Il existe des règles de gouvernance du code dans le dépôt qui en assure la qualité et la stabilité.
Exigence O 4.9 Le code est muni d’une documentation adéquate et des guides de code répliquable.
Exigence O 4.10 Fournir un graphe de compatibilité de la (les) licence(s) libre(s) utilisée(s).
Exigence D 5.1 Les données sont un bien précieux protégé par des mesures de sécurité adéquates. La protection des données est l'affaire de tous, des mesures de sensibilisation et de valorisation des données sont documentées.
Exigence D 5.2 Les données sont disponibles selon une politique de données ouvertes claire, une licence d’utilisation permettant une large gamme d’usages et une gouvernance bien définie.
Exigence D 5.3 Utilisation de format ouvert pour assurer l'interopérabilité et la portabilité des données
Exigence D 5.4 Les contributions favorisent des outils et un mode de stockage infonuagique de données.
Exigence D 5.5 Le données sont catégorisées et il existe une séparation entre les données (BD dédiée, schéma dédié, ..). Données système, données publiques, données personnelles accessibles avec consentement, autres
Exigence D 5.6 Des diagrammes qui documentent les échanges de données entre les composants et avec les services internes et externes sont disponibles.
Exigence D 5.7 Appliquer des techniques d'anonymisation lorsque les données sont partagées hors du cadre de sécurité.
Exigence D 5.8 Assurer le consentement des parties lors de la collecte et l'utilisation de leurs données et aussi des technologies d'identification personnelle
Exigence D 5.9 Favoriser l’hébergement des données au Canada
Exigence R 6.1 Il offre des Services/API aux applications clients (voir principe 2.) qui adhèrent aux standards métiers (REST, GraphQL, OAuth, OData, et autres)
Exigence R 6.2 Suivre les meilleures pratiques d’essais unitaires.
Exigence R 6.3 Il existe des environnements de développement, d'essai et de production séparés
Exigence R 6.4 Processus de déploiement automatisé
Exigence R 6.5 Analyse automatisé du code : Outils et processus
Exigence R 6.6 Plusieurs paliers / plateformes de déploiement. (Dév, QA, Acceptation, Prod, Relève,..)
Exigence R 6.7 Entrepôt de code et contrôle des versions d’une contribution
Exigence R 6.8 Les applications web respectent une conception web adaptative (Responsive Design)
Exigence R 6.9 Tests de conformité du code web. Markup Validation Service CSS Validation Service
Exigence R 6.10 Processus de révision du code et contrôle de la qualité
Exigence R 6.11 Les applications web respectent une conception web adaptative (Responsive Design)
Exigence R 6.12 Les systèmes et services sont conçus orientés infonuagique: Déploiement automatisé infonuagique Passage à l'échelle spontané Balancement de charge géo localisé Etc…
Exigence R 6.13 Suivre une méthodologie de travail qui permet le suivi et la communication de l'avancement.
Exigence R 6.14 Mise en place et publication d'une feuille de route des livraisons des fonctionnalités
Exigence I 7.1 Les services et applications web emploient un standard d'autorisation Oauth 2.0
Exigence I 7.2 Identité des utilisateurs est fournie par un standard OpenId Connect Fournisseur(s) d’identité (Azure, Google, AWS, GitHub, Open Source,..)
Exigence I 7.3 Les services et applications ne dépendent pas d'un fournisseur en particulier. Possibilité d’identité de fournisseurs variés
Exigence I 7.4 Le(s) flux d’autorisation utilisés (Implicit, Authorization Code, Resource Owner Password, Client Credentials,..) sont documentés.
Exigence I 7.5 Les services et applications utilisent un système d'IAM qui permet la gestion du consentement des utilisateurs.
Exigence I 7.6 Dans un contexte d'interaction entre les services du programme MeC, les services et applications adopte un contexte d'authentification uniques SSO (Single Sign-On)
Exigence I 7.7 L'accès aux fonctionnalités des services et applications est contrôlé par des autorisations granulaires (rôles RBAC et revendications)
Exigence I 7.8 Lors des appels aux services internes d'arrière-plan, la validité des jetons d'accès est vérifiée.
Exigence I 7.9 Documenter le mécanisme de protection des services internes (Passerelle d'API, autres)
Exigence I 7.10 Offrir plusieurs portes d'entrée selon la clientèle ciblée. Modèle de sécurité B2B, B2C, utilisateurs internes (ex. Resource Owner Password)
Exigence S 8.1 Un plan de mise à jour bien défini qui permet de corriger les failles de sécurité
Exigence S 8.2 Fournir la liste des vulnérabilités connues et les mesures préconisés pour les adresser Consulter les registres des vulnérabilités
Exigence S 8.3 Des processus d'analyse des journaux et de notifications spontanées sont mis en place.
Exigence S 8.4 Prévoir un plan d’action en cas de faille de sécurité
Exigence S 8.5 Documenter et promouvoir les meilleures pratiques de contrôle, durcissement et révision du code
Exigence S 8.6 Les données des applications et services sont encryptées au repos
Exigence S 8.7 Les échanges de données sont faits par l'entremise de canaux encryptés de transmission
Exigence S 8.8 Journalisation des accès aux ressources et traçabilité Présenter des évidences (captures d’écran par exemple)
Exigence V 9.1 La livraison de services suit une approche itérative d'analyse et de mitigation des risques.
Exigence V 9.2 La conception et réalisation des applications respectent les recommandations et standards de l’OWASP
Exigence V 9.3 Un processus est mis en place pour rester informé des vulnérabilités associées aux composants utilisés.
Exigence V 9.4 Une politique de transparence permettant la communication des risques et de vulnérabilité aux parties prenantes.
Exigence V 9.5 Évaluation continue des risques et vulnérabilité et application des nouvelles mesures lorsqu’ils sont rendus disponibles.
Exigence V 9.6 Analyse de l'impact des modifications planifiées et communication de l'impact aux parties prenantes et consommateurs des services.
Exigence V 9.7 Toutes les contributions doivent entreprendre en particulier une analyse du risque d'exposition des données privées.
Exigence V 9.8 Utilisation des outils d'instrumentations des fonctionnalités clés des services offertes.
Exigence A 10.1 Conformer en tout temps à un niveau d'accessibilité AA ou plus.
Exigence A 10.2 Accès à partir des différents types d'appareils portatifs (BYOD). Standards du marché et l’accès des solutions Internet et mobiles.
Exigence A 10.3 Assurer une conception Adaptative (Responsive design) et support des fureteurs variés.
Exigence A 10.4 Proposer des alternatives textuelles à tout contenu non textuel.
Exigence A 10.5 Fournir des sous-titres et autres alternatives pour le multimédia.
Exigence A 10.6 Créer des contenus qui peuvent être présentés de différentes manières, y compris par les technologies d’assistance, sans perdre la signification.
Exigence A 10.7 Faciliter la perception visuelle et auditive du contenu par l’utilisateur.
Exigence A 10.8 Rendre toutes les fonctionnalités accessibles au clavier.
Exigence A 10.9 Laisser à l’utilisateur suffisamment de temps pour lire et utiliser le contenu.
Exigence A 10.10 Ne pas concevoir de contenu susceptible de provoquer des crises ou des réactions physiques.
Exigence A 10.11 Aider l’utilisateur à naviguer et trouver le contenu.
Exigence A 10.12 Faciliter l’utilisation d’outils de saisie autres que le clavier.
Exigence A 10.13 Rendre le texte lisible et compréhensible.
Exigence A 10.14 Faire en sorte que les contenus apparaissent et fonctionnent de manière prévisible.
Exigence A 10.15 Aider l’utilisateur à éviter et corriger les erreurs.
Exigence A 10.16 Considérer la compatibilité avec les outils des utilisateurs actuels et futurs.
Exigence U 11.1 Collecter seulement les données nécessaires pour une finalité établie et une mission énoncée
Exigence U 11.2 Limiter le stockage et définir un cycle de vie des données numériques
Exigence U 11.3 Construire un catalogue de données qui documente la raison de collecte et la durée de vie des données
Exigence U 11.4 Assurer un lien de confiance - rendre disponible l’ensemble des informations sur les modes de gestion, risques, garanties et droits liés au traitement des données de manière compréhensible pour tous.
Exigence U 11.5 Promouvoir la participation publique et faire recours à l'imagination collective dans la recherche de solutions aux problèmes, et aussi dans les décisions collectives autour des données.
Exigence U 11.6 Suivre une approche expérimentale qui implique la ville de Montréal lorsqu’on risque de ne pas conformer à ce principe.
Exigence U 11.7 Faire une analyse des enjeux sociaux des parties prenantes potentiellement affectées par le changement proposé
Exigence L 12.1 Il existe une procédure claire de vérification de la conformité avec les règlements, lois et recommandations; données privées, acceptabilité sociales, autres
Exigence L 12.2 Il existe une culture et des formations pour sensibiliser les employés au respect des législations qui gouvernent la prestation des services de l’entreprise.
Exigence L 12.3 Les messages électroniques commerciaux respectent la loi anti-pourriels
Exigence L 12.4 Mettre en place des procédures de signalement d'incidents de confidentialité qui informent les parties prenantes concernées de la portée et des implications des incidents
Exigence L 12.5 Il existe une culture de sensibilisation aux législations fédérales et provinciales destinées à la protection des consommateurs. Cette sensibilisation est particulièrement importante dans les domaines de services alimentaires et services
Exigence L 12.6 Le déploiement des équipements et l’aménagement des locaux et entrepôts sont soumises à des vérifications des législations gouvernant l’occupation du domaine public.
Exigence J 13.1 Les mesures de réduction de la fracture numérique sont identifiées et observées au sein des équipes de réalisation
Exigence J 13.2 Minimiser la dépendance de la disponibilité des technologies avancées et de connaissances technologiques auprès des utilisateurs pour assurer l'universalité d'accès.
Exigence J 13.3 Les services offerts sont accessibles par tous. Des alternatives raisonnables sont disponibles par exemple lorsqu'un service requiert des dépendances techniques restrictives.
Exigence J 13.4 Réduire la fracture numérique - développer une littératie et une compétence numérique par la documentation continue de l'usage et la visualisation des données.
Exigence J 13.5 Application de l’ADS+ dans la collecte, le traitement, l’analyse et la diffusion des données
Exigence G 15.1 Les produits et services sont munis d'une documentation exhaustive et compréhensive.
Exigence G 15.2 Les produits et services sont répliquables
Exigence G 15.3 Des plans d'évaluation des contraintes non-fonctionnelles sont établis. Métriques de performance, métriques de disponibilité, plages de maintenance
Exigence G 15.4 Support adéquat aux utilisateurs des services et produits. Plusieurs niveaux de support.
Exigence G 15.5 Livraison des nouvelles versions des services et produits dans un mode CI/CD - Intégration continue et déploiement continu.
Exigence G 15.6 Plan de passage à l'échelle prévu pour accommoder une clientèle grandissante.
Exigence G 15.7 Les fichiers de journalisation sont surveillés, accessibles et disponibles pour analyse et audit.
Exigence G 15.8 Les cédules des travaux automatisés et flux de données sont documentés et publiés
Exigence G 15.9 Les utilisateurs sont informés des niveaux de services SLA des différents composants des systèmes.
Exigence G 15.10 Outils de duplications des données entre les environnements (Prod / Non-Prod) qui assurent la protection des données personnelles.
Exigence G 15.11 Posséder des plans de continuité des activités BCPs
Exigence G 15.12 Prévoir des plans de migration des applications et services. Différentes plateformes, nouvelles versions des plateformes
Exigence G 15.13 Un système doit avoir la possibilité de passer facilement entre les modes en ligne / hors ligne
Exigence G 15.14 Un système doit avoir des procédures de sauvegarde et de restauration des données.
Exigence G 15.15 Il existe des documentations techniques, opérationnelles et utilisateur qui inclut les détails techniques, les configurations, les infrastructures, et autres.
Établir de nouveaux partenariats et réseaux
Obtenir des résultats pour les résidents
Généraliser les bénéfices
Habiliter les collectivités à innover
Les principes directeurs d'architecture de MeC Etablir une architecture de solution intégrée, adaptable et évolutive
Principe 15 Standards de gestion opérationnelle des solutions Assurer la continuité et la robustesse
Principe 9 Identification, évaluation et atténuation des risques Assurer la continuité et la robustesse
Principe 3 Neutralité technologique Offrir des services faciles à évoluer
Principe 3 Neutralité technologique Diminuer le menottage technologique
Principe 2 Architecture intégrée, modulaire et réutilisable Offrir des services faciles à évoluer
Principe 1 Primauté des principes d’architecture Offrir des services faciles à évoluer
Principe 11 Acceptabilité sociale et utilisation des données éthique et responsable Respecter la charte des données numériques de la ville
Principe 12 Conformité législative Assuer l'accès aux données pour offrir des services de qualité
Principe 12 Conformité législative Respecter la charte des données numériques de la ville
Principe 13 Inclusion numérique Diminuer la fracture technologique
Principe 14 Écoconception des services et produits Réduire l'empreinte écologique
Principe 8 Sécurité optimale Assuer l'accès aux données pour offrir des services de qualité
Principe 4 Logiciels et matériels libres Offrir des services faciles à évoluer
Principe 4 Logiciels et matériels libres Favoriser le partage d'experiences
Principe 5 Les données sont un bien précieux partageable Respecter la charte des données numériques de la ville
Principe 5 Les données sont un bien précieux partageable Assuer l'accès aux données pour offrir des services de qualité
Principe 6 Standardisation Offrir des services faciles à évoluer
Etablir une architecture de solution intégrée, adaptable et évolutive Services numériques
Optimiser l'allocation et la rentabilité du financement INFC
Optimiser l'allocation et la rentabilité du financement Il est temps d'agir contre le changement climatique
Optimiser l'allocation et la rentabilité du financement Établir de nouveaux partenariats et réseaux
Optimiser l'allocation et la rentabilité du financement Obtenir des résultats pour les résidents
Optimiser l'allocation et la rentabilité du financement Généraliser les bénéfices
Optimiser l'allocation et la rentabilité du financement Habiliter les collectivités à innover
Réplicabilité Une seule ville bénéficie du financement
Pérennisation Les engagements sont limités à la durée du financement
Services Accessibles Les personnes vulnérables ont accès à des service de piètre qualité
Services Accessibles Une dépendence croissante des plateformes numériques
Services Accessibles Certains citoyens n'ont pas accès aux services
Ville de Montréal Livrer la vision gagnante du défi
Livrer la vision gagnante du défi Données numériques non accessibles
Livrer la vision gagnante du défi Économie du quartier sous-valorisée
Livrer la vision gagnante du défi Équipements et locaux sous utilisés
Livrer la vision gagnante du défi Les personnes vulnérables ont accès à des service de piètre qualité
Livrer la vision gagnante du défi Données numériques abandantes sous-exploitées
Livrer la vision gagnante du défi Manque de clarté des besoins et leurs pertinences
Livrer la vision gagnante du défi Il est temps d'agir contre le changement climatique
Économie du quartier sous-valorisée Mutualisation
Données numériques abandantes sous-exploitées Données ouvertes
Diminuer la fracture technologique Services Accessibles
Offrir des services faciles à évoluer Pérennisation
Offrir des services faciles à évoluer Approche expérimentale
Données numériques non accessibles Données ouvertes
Diminuer le menottage technologique Réplicabilité
Favoriser le partage d'experiences Réplicabilité
Manque de clarté des besoins et leurs pertinences Approche expérimentale
Assuer l'accès aux données pour offrir des services de qualité Données ouvertes
Respecter la charte des données numériques de la ville Données ouvertes
Services numériques Une dépendence croissante des plateformes numériques
Assurer la continuité et la robustesse Pérennisation
Écoconception Il est temps d'agir contre le changement climatique
Réduire l'empreinte écologique Écoconception
Équipements et locaux sous utilisés Mutualisation
Exigence P 1.1 Les principes directeurs d'architecture sont communiqués aux équipes de réalisation internes/externes Principe 1 Primauté des principes d’architecture
Exigence P 1.2 Le choix des composants de solutions est validé pour assurer la conformité avec les principes directeurs Principe 1 Primauté des principes d’architecture
Exigence P 1.3 Toutes les divergences des principes directeurs sont documentées, justifiées et communiquées au comité TI Principe 1 Primauté des principes d’architecture
Exigence P 1.4 L'analyse de conformité avec les principes directeurs est maintenue à jour. Cette analyse est révisée par exemple avec tout changement significatif aux services Principe 1 Primauté des principes d’architecture
Exigence P 1.5 L'analyse de conformité avec les principes directeurs est un livrable requis avec chaque livraison de services dans le cadre du programme MeC Principe 1 Primauté des principes d’architecture
Exigence M 2.1 La documentation de l'architecture des services et systèmes est disponible et accessible. Fonctionnelle, applicative, données, technologique Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.2 Les services exposent des interfaces APIs disponibles aux parties tierces sans restrictions ou conditions sur le type des applications clientes. Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.3 Un inventaire d'APIs est disponible, documenté et accessible. L’inventaire des API est mis à jour et intégré dans l'inventaire des APIs du programme MeC. Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.4 L'architecture est modulaire. Il existe un référentiel de modules réutilisables à la disposition des équipes de réalisation internes ou externes. Le référentiel est intégré dans le référentiel des modules du programme MeC. Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.5 Un système doit être modulaire permettant d'activer / désactiver des fonctionnalités sans interruption des services du système entier. Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.6 L'architecture de la solution prévoit un processus automatisé de déploiement et de passage à l’échelle Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.7 L'architecture respecte le faible couplage des services Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.8 L'architecture de la solution et la conception des services respectent le libre flux de données Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.9 La documentation de l'architecture contient la gouvernance et la sécurité au niveau des services Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.10 La documentation de l'architecture identifie le composants critiques au fonctionnement du système Principe 2 Architecture intégrée, modulaire et réutilisable
Exigence M 2.11 L'architecture prévoit des coupes-feu d’échec et des relèves au niveau des services Principe 2 Architecture intégrée, modulaire et réutilisable
Établir de nouveaux partenariats et réseaux Les engagements sont limités à la durée du financement
Obtenir des résultats pour les résidents Certains citoyens n'ont pas accès aux services
Généraliser les bénéfices Une seule ville bénéficie du financement
Habiliter les collectivités à innover Une dépendence croissante des plateformes numériques