Owen Sound : Un plan d'affaires municipal sur quatre ans

Accueil › Information, confidentialité et indépendance numérique canadienne › Chapitre 32

Information, confidentialité et indépendance numérique canadienne

Chapitre 32Souveraineté numérique canadienne

10,543 mots · Mike Seiler · Owen Sound, Ontario

Ouvrir dans le lecteur →

Votez sur les propositions, écoutez l’audio, lisez les examens, cherchez dans tout le plan.

Dans ce chapitre

Une ville peut perdre le contrôle pratique d'un service public essentiel sans vendre un bâtiment, une route ou une usine d'eau.

Cela peut arriver par l'intermédiaire d'un contrat logiciel.

Une municipalité peut toujours être propriétaire légalement de ses données tout en devenant dépendante opérationnellement de :

Ensuite, le fournisseur :

La ville découvre qu'elle possède techniquement les données, mais ne peut pas facilement fonctionner sans le fournisseur.

Cela constitue une forme de dépendance.

Le plan initial propose de transférer map.ca vers une propriété publique protégée avant toute adoption municipale, considérant l'infrastructure des données comme quelque chose que la communauté devrait pouvoir contrôler plutôt que simplement louer indéfiniment. Il propose également une gestion des données axée sur les résidents plutôt que sur la publicité et le suivi comme base des systèmes numériques publics.

Cette idée s'inscrit dans un principe beaucoup plus large :

Owen Sound devrait contrôler le service public, les données publiques et la capacité de continuer à fonctionner, même lorsqu'elle ne possède pas chaque composant technologique sous-jacent.

Le gouvernement du Canada définit maintenant la souveraineté numérique de manière très similaire : la capacité d'exercer un pouvoir d'autonomie sur l'infrastructure numérique, les données et la propriété intellectuelle, et de continuer à prendre des décisions indépendantes concernant les actifs numériques, peu importe où les technologies sous-jacentes ont été développées, hébergées ou soutenues.

C'est la définition que j'adopterais pour Owen Sound.

La souveraineté numérique ne signifie pas :

Tout doit être construit à Owen Sound.

Elle ne signifie pas :

Chaque serveur doit être installé à la mairie.

Elle ne signifie pas :

Ne jamais utiliser une entreprise américaine.

Elle signifie :

Jamais devenir si dépendant d'une seule entreprise technologique extérieure que Owen Sound ne puisse raisonnablement pas changer de direction sans perdre le service public sous-jacent.

Le test le plus simple est :

Pouvons-nous partir ?

Si la réponse est non :

Nous ne contrôlons pas pleinement le système.

32.1La souveraineté est un contrôle pratique

Une municipalité peut posséder un ensemble de données en théorie tout en n'ayant pas de contrôle pratique sur celui-ci.

Pour chaque système important, posez-vous les questions suivantes :

La ville peut-elle accéder à ses données ?

La ville peut-elle les exporter ?

L'exportation est-elle utilisable ailleurs ?

Un autre fournisseur qualifié peut-il exploiter le service ?

La ville peut-elle continuer temporairement si le fournisseur disparaît ?

La ville comprend-elle ses dépendances critiques ?

La ville contrôle-t-elle l'identité publique du service ?

Le conseil municipal peut-il modifier sa politique sans avoir besoin de la permission d'un fondateur ou d'un fournisseur privé ?

Si la réponse est non, la dépendance doit être comprise avant la signature du prochain contrat.

32.2La souveraineté n'est pas l'isolement

Owen Sound devrait continuer à utiliser une excellente technologie provenant de :

lorsque cela offre la meilleure valeur publique licite.

Essayer de produire nous-mêmes chaque logiciel serait :

L'objectif n'est pas le nationalisme technologique pour le plaisir.

L'objectif est l'indépendance stratégique.

Le cadre fédéral de souveraineté numérique traite de la souveraineté comme quelque chose à accroître proportionnellement, plutôt que d'exiger que chaque technologie provienne ou s'exécute exclusivement au Canada.

32.3Achetez des capacités, pas de la captivité

Une bonne relation avec un fournisseur peut durer vingt ans.

Cela est parfaitement acceptable.

Le problème survient lorsque la relation dure vingt ans parce qu'il devient impossible de s'en éloigner.

Un contrat municipal devrait permettre à Owen Sound de rester avec un fournisseur parce que :

Ils continuent à offrir une excellente valeur.

Et non parce que :

Nous ne pouvons pas échapper au système.

32.4La question de la souveraineté municipale

Avant d'approuver une technologie importante, le conseil municipal devrait être en mesure de comprendre :

Quelle partie de ce système Owen Sound contrôle-t-elle réellement ?

Cette réponse peut inclure :

Cela peut aussi révéler des éléments contrôlés par le fournisseur.

Aucun de ces deux aspects n'est automatiquement négatif.

La dépendance doit simplement être visible.

L'indépendance numérique municipale ne remplace pas les lois existantes de l'Ontario sur la vie privée et l'accès à l'information.

La Loi sur l'information municipale et la protection de la vie privée établit à la fois les principes d'accès public aux informations municipales et les protections de la vie privée pour les renseignements personnels détenus par les institutions municipales.

L'Ontario a également adopté la Loi sur la cybersécurité et la confiance numérique, 2024, qui établit un cadre législatif permettant d'appliquer des exigences de cybersécurité et d'intelligence artificielle aux entités du secteur public, y compris celles couvertes par la Loi sur l'information municipale et la protection de la vie privée.

À partir du 1er juillet 2026, la réglementation actuelle sur la cybersécurité de l'Ontario, édictée en vertu de cette loi, s'applique à certains établissements d'éducation, certains hôpitaux, certaines sociétés d'aide aux enfants et certains conseils scolaires. Les municipalités ne figurent pas parmi les entités visées par cette réglementation particulière à ce moment.

Cette distinction est importante.

Owen Sound ne devrait pas affirmer :

L'Ontario exige actuellement ce programme exact de cybersécurité municipale

si la réglementation actuelle ne l'exige pas.

L'approche plus judicieuse est :

Établir des pratiques municipales solides parce qu'elles sont prudentes, qu'elles répondent aux obligations actuelles de la municipalité et qu'elles préparent à un cadre provincial en évolution.

32.6La norme municipale peut dépasser le minimum

L'obligation légale est le seuil minimum.

Et non la stratégie.

Si la loi exige :

la ville peut tout de même décider que :

est une meilleure gestion publique.

Les mesures de protection supplémentaires devraient rester :

32.7Les sept couches de la souveraineté numérique

Chaque système important de la ville devrait être examiné selon sept couches.

1. Service public

Quel est le besoin réel des citoyens ?

2. Données

Qui contrôle l'information ?

3. Identité

Qui contrôle les utilisateurs, les comptes et l'authentification ?

4. Logiciel

Qui contrôle l'application et la configuration ?

5. Infrastructure

Où est-elle déployée ?

6. Fournisseur

Qui fournit et soutient le système ?

7. Connaissances

Est-ce que quelqu'un à l'intérieur de la ville ou disponible pour la ville comprend comment le système fonctionne ?

Un système peut tomber en panne à n'importe quel niveau.

32.8Commencez par le service

Ne commencez pas un achat technologique en posant la question suivante :

Quel logiciel devrions-nous acheter ?

Commencez plutôt par :

Quel service public essayons-nous de fournir ?

Puis posez-vous la question suivante :

Quelle technologie est réellement nécessaire ?

Cela empêche la ville d'acheter d'abord une plateforme et de restructurer le service public autour de ce que la plateforme fait.

32.9La technologie sert la politique

Le conseil municipal établit la politique publique légale.

La technologie la met en œuvre.

La direction ne devrait pas être inversée.

Si un fournisseur dit :

Notre logiciel ne peut pas soutenir cette politique, alors changez la politique,

le conseil municipal devrait se demander si :

L'architecture logicielle privée ne devrait pas devenir discrètement la loi municipale.

32.10Classer les systèmes selon leur importance

Pas tous les systèmes ont besoin du même standard de souveraineté.

Un outil utilisé pour concevoir un affiche de loisir est différent d'un logiciel contrôlant :

Créez des niveaux.

Critique

Une panne pourrait affecter de manière significative :

Importante

Une panne perturbe matériellement les opérations de la ville, mais peut être tolérée temporairement.

Routinière

Une panne est gênante, mais ne perturbe pas sérieusement le service municipal.

Dépensez l'argent de résilience selon les conséquences.

32.11Systèmes numériques municipaux critiques

La revue devrait inclure les systèmes qui soutiennent des fonctions telles que :

Ceci n'est pas une déclaration que chaque système de ces catégories présente un risque identique.

L'objectif est d'identifier là où la dépendance est la plus critique.

32.12L'indice des systèmes numériques

Ajouter une couche numérique à l'indice des infrastructures et systèmes de la section 12.

Pour les systèmes importants, noter les éléments suivants :

Ne pas exposer publiquement les détails de sécurité qui rendraient les systèmes plus vulnérables aux attaques.

Tenir un registre interne sécurisé et publier un résumé public sécurisé.

32.13Connaître le fournisseur

Pour chaque service numérique majeur, Owen Sound devrait connaître :

La marque affichée à l'écran de connexion ne représente peut-être qu'une seule partie de la chaîne d'approvisionnement.

32.14Connaître la chaîne de dépendance

Une ville peut acheter un logiciel chez l'entreprise A.

L'entreprise A peut dépendre de :

La ville n'a pas besoin de cartographier l'internet entier.

Elle devrait comprendre les dépendances majeures dont la panne pourrait interrompre un service public important.

Le Centre canadien de la cybersécurité inclut spécifiquement la gestion de la chaîne d'approvisionnement, l'interopérabilité, la portabilité, la sécurité des données et la continuité des affaires parmi les domaines que les organisations devraient évaluer lorsqu'elles examinent la sécurité des services en nuage.

32.15Concentration des fournisseurs

Poser la question suivante :

Combien de systèmes critiques de la ville tomberaient-ils en panne si ce seul fournisseur échouait ?

L'utilisation d'un seul fournisseur peut créer :

Cela peut aussi créer un risque de concentration.

L'équilibre approprié dépend du service.

Ne pas diversifier uniquement pour avoir plus de fournisseurs.

Ne pas regrouper uniquement parce qu'un fournisseur propose un forfait.

Comprendre les conséquences.

32.16Test de sortie

Chaque acquisition majeure de logiciel devrait répondre à la question suivante avant l'achat :

Si nous décideons de quitter ce fournisseur dans cinq ans, qu'est-ce qui se passera exactement ?

La réponse devrait identifier :

Cela devient le test numérique de sortie.

32,17 L'exportation n'est pas suffisante

Un fournisseur peut dire:

Vous pouvez exporter vos données à tout moment.

Demandez:

Dans quel format ?

Dix millions de lignes à l'intérieur d'un fichier propriétaire non documenté peuvent être techniques, mais c'est une exportation.

Cela peut s'avérer pratiquement inutilisable.

La ville a besoin de :

Le test est la portabilité utilisable.

32,18 Exportation avant renouvellement

Avant de renouveler un système majeur, effectuez un test d'exportation, si possible.

N'attendez pas un différend contractuel pour découvrir :

Un test d'exportation périodique est une prévention incendie numérique.

32,19 Normes ouvertes

Préférez les normes largement documentées et interopérables lorsqu'elles répondent raisonnablement aux besoins.

Les normes ouvertes peuvent faciliter :

Le gouvernement du Canada identifie de manière similaire les normes ouvertes et l'approvisionnement interopérable comme des outils facilitant la continuité et réduisant la dépendance.

32,20 L'ouvert n'implique pas l'inaccessible

Un format de fichier documenté peut être ouvert.

Les données elles-mêmes peuvent rester :

Ne confondez pas :

norme ouverte

avec

accès libre.

L'un concerne la portabilité.

L'autre concerne la permission.

32,21 Interfaces de programmation d'applications

Lorsque des systèmes doivent communiquer, privilégiez des interfaces documentées, si possible.

Une interface permet à un système d'échanger des informations avec un autre sans tout reconstruire manuellement.

Avant de s'appuyer sur une interface, il faut connaître :

Une interface contrôlée entièrement à la discrétion d'un fournisseur reste une dépendance.

32,22 Éviter le verrouillage personnalisé inutile

Le logiciel personnalisé peut être utile.

Il peut aussi créer une dépendance envers la seule personne qui le comprend.

Si la ville achète un développement personnalisé important, établissez :

La structure exacte de la propriété intellectuelle dépend de l'acquisition.

L'ignorance ne devrait pas en faire partie.

32.23Code source

La ville n'a pas besoin du code source de chaque produit commercial qu'elle utilise.

Cependant, pour les systèmes hautement personnalisés ou essentiels, le conseil municipal devrait comprendre ce qui se passe si le développeur :

Les mesures de protection possibles peuvent inclure :

Choisissez la mesure de protection proportionnée au risque.

32.24La documentation est une infrastructure

Un système que personne ne comprend, sauf un seul employé ou un contractant, est fragile.

Les systèmes importants nécessitent une documentation appropriée couvrant :

La documentation doit être mise à jour lorsque le système change.

Elle ne doit pas être écrite une fois et oubliée.

32.25Concentration des connaissances

Posez-vous la question suivante :

Que se passera-t-il si la seule personne qui connaît ce système prend sa retraite demain?

Cette question s'applique à :

Créez :

La souveraineté numérique signifie aussi la souveraineté des connaissances.

32.26Calcul en nuage

Le calcul en nuage peut offrir :

Les directives du Centre canadien de la cybersécurité reconnaissent ces avantages tout en soulignant que les organismes doivent évaluer et gérer les risques spécifiques au nuage tout au long du cycle de vie du service.

La politique ne devrait pas être :

Le nuage est mauvais.

Ni :

Le nuage est toujours meilleur.

Elle devrait être :

Choisissez l'architecture qui gère le mieux le risque et le coût réels.

32.27Hébergement interne

Exécuter soi-même les systèmes peut offrir un contrôle direct plus important dans certains cas.

Cela crée aussi des responsabilités concernant :

L'hébergement interne n'est pas une souveraineté si la ville ne possède pas la capacité d'opérer en toute sécurité.

32.28Architecture hybride

Certains systèmes municipaux futurs pourraient raisonnablement utiliser :

Ensemble.

L'architecture devrait suivre :

Ne pas transformer un modèle technologique en idéologie.

32.29Résidence des données

Lorsque des données publiques sensibles sont impliquées, la ville devrait savoir où elles se trouvent :

La résidence au Canada peut réduire certains risques juridiques et opérationnels et peut être souhaitable ou exigée dans certaines circonstances.

Mais l'emplacement seul ne crée pas une souveraineté complète.

32.30La résidence n'est pas la même que la juridiction

L'analyse du gouvernement du Canada en 2026 sur le nuage public souligne explicitement que même les données stockées physiquement à un endroit particulier peuvent être affectées par la loi étrangère selon le fournisseur et son exposition juridique internationale.

Par conséquent :

Données au Canada

et

Données sous contrôle juridique exclusivement canadien

ne sont pas automatiquement la même affirmation.

La ville devrait examiner :

avec l'expertise juridique appropriée.

32.31Prédilection pour l'hébergement canadien

Pour certains systèmes sensibles ou critiques sélectionnés, Owen Sound devrait examiner si l'hébergement canadien améliore matériellement :

Cette prédilection devrait néanmoins prendre en compte :

L'objectif est la réduction des risques.

Pas un drapeau à côté du serveur.

32.32Un fournisseur canadien ne signifie pas automatiquement une souveraineté

Une entreprise canadienne peut elle-même dépendre presque entièrement de :

Cela ne rend pas l'entreprise inadéquate.

Cela signifie que l'on doit quand même comprendre la dépendance sous-jacente.

Demandez un niveau plus profond.

32.33Fournisseur étranger ne signifie pas automatiquement inadéquat

De même, un fournisseur international peut offrir :

Évaluez le système.

Et non le passeport du vendeur.

32.34Capacité canadienne

Là où les fournisseurs canadiens peuvent offrir un équivalent ou une meilleure :

la ville devrait s'efforcer d'assurer qu'ils aient une chance équitable de concourir dans le cadre des règles applicables d'approvisionnement et de commerce.

Cela s'inscrit directement dans la Section 11.

Renforcez la capacité canadienne grâce à une chance équitable, et non à une faveur cachée.

32.35Entreprises technologiques locales

Les entreprises technologiques d'Owen Sound et de Grey Bruce devraient, de la même manière, avoir un accès compréhensible aux marchés publics.

Cela ne signifie pas :

L'entreprise locale gagne automatiquement.

Cela signifie :

Les systèmes publics exigent quand même des normes professionnelles.

32.36Risque des petits fournisseurs

Une petite entreprise canadienne peut offrir :

Elle peut aussi faire face à :

La ville peut atténuer ces risques grâce à des garanties contractuelles appropriées.

Soutenir les technologies locales ne nécessite pas de prétendre que les risques n'existent pas.

32.37Risque des grands fournisseurs

Un fournisseur multinational peut sembler stable.

Il peut quand même :

La taille élimine certains risques.

Elle en crée d'autres.

Le Test de sortie numérique s'applique à tout le monde.

32.38Questions d'approvisionnement

Chaque approvisionnement numérique important devrait répondre à :

Quel service public est-ce que cela soutient ?

Quelles informations est-ce qu'il gère ?

Quelle est la classification de sécurité ?

Où sont stockées les informations ?

Qui peut y accéder ?

Quels sont les principaux sous-traitants ?

La ville peut-elle exporter tout ?

Quel format ?

Quel est le coût de la sortie ?

Quel est le déroulement lorsque le contrat arrive à son terme ?

Comment sont gérés les manquements au contrat ?

Comment sont gérés les sauvegardes ?

Quel est le déroulement si le fournisseur n'est pas disponible ?

Les questions appartiennent à l'approvisionnement avant l'achat.

32.39Le prix n'est qu'un coût

Un contrat de logiciel peut coûter :

20 000 $ par année.

Le coût réel peut inclure également :

La norme financière s'applique.

Calculer le cycle de vie complet.

32.40Une adoption abordable peut signifier un coût élevé pour la sortie

Certaines plateformes rendent l'adoption initiale très abordable.

Des années plus tard, la migration peut devenir extrêmement coûteuse, car :

Cela ne signifie pas qu'il faut éviter la plateforme.

Cela signifie qu'il faut inclure le coût futur de la sortie lors de l'évaluation d'une offre abordable aujourd'hui.

32.41Calendrier des renouvellements de contrat

Tenir un calendrier central des contrats majeurs en technologie :

Une municipalité ne devrait pas découvrir :

Le contrat se renouvelle automatiquement demain

alors que le conseil municipal souhaitait examiner d'autres options.

32.42Aucun renouvellement automatique accidentel

Lorsque cela est pratique et contractuellement possible, les systèmes importants devraient faire l'objet d'une évaluation délibérée avant de s'engager à long terme.

L'évaluation peut être proportionnelle.

Les abonnements routiniers à faible risque n'ont pas besoin d'être débattus par le conseil municipal.

Les systèmes critiques à plusieurs années en ont besoin.

32.43Classification des données

Owen Sound devrait établir une approche interne claire pour distinguer les informations selon leur sensibilité et leur importance opérationnelle.

Des catégories générales pourraient inclure :

Le cadre exact devrait être établi par du personnel qualifié ainsi que des professionnels en droit et en protection de la vie privée.

Des informations différentes méritent des mesures de protection différentes.

32.44Ce n'est pas tout qui est sensible

Une classification excessive crée :

Une carte de parc n'est pas un mot de passe de contrôle de traitement d'eau.

Appliquer une sécurité proportionnelle aux conséquences.

32.45Ce n'est pas tout qui est public

Le principe d'ouverture gouvernementale a aussi des limites.

Les renseignements pouvant exposer :

peuvent nécessiter une protection conformément à la loi applicable.

L'ouverture par défaut ne signifie pas une publication téméraire.

La Ville ne peut exercer une souveraineté numérique significative si elle ne connaît pas :

Les finalités de la Loi sur l'accès à l'information municipale et la protection des renseignements personnels (LARMPR) comprennent la protection de la vie privée des individus concernant les renseignements personnels détenus par les institutions municipales, tout en offrant des droits d'accès appropriés.

La gouvernance des données et la souveraineté s'inscrivent donc dans une même démarche.

32.47Minimisation des données

La méthode la plus simple pour réduire de nombreux risques liés à la vie privée et à la cybersécurité est la suivante :

N'acquérir que les renseignements nécessaires.

Chaque champ superflu devient un autre :

Une bonne gouvernance des données commence avant le stockage.

32.48Chiffrement

Les renseignements sensibles appropriés devraient utiliser des contrôles de sécurité adéquats, y compris le chiffrement, lorsque cela est requis par le risque et les normes professionnelles.

Le travail du gouvernement fédéral sur la souveraineté des nuages identifie le chiffrement et le contrôle des clés cryptographiques parmi les outils utilisés pour réduire l'exposition des renseignements protégés.

L'implémentation technique devrait être déterminée par des professionnels qualifiés.

Le conseil municipal devrait comprendre la question de gouvernance suivante :

Qui contrôle finalement l'accès ?

32.49Clés de chiffrement

Pour les systèmes particulièrement sensibles, il convient d'examiner :

Le chiffrement le plus robuste au monde n'est pas utile si :

La sécurité exige aussi la récupérabilité.

32.50L'identité est une infrastructure

Une municipalité dépend de plus en plus de l'identité numérique :

Si l'identité échoue, de nombreux services peuvent échouer simultanément.

Traiter les systèmes d'identité comme une infrastructure critique, lorsque cela convient.

32.51Propriété du domaine municipal

La Ville devrait maintenir un contrôle clair sur ses domaines officiels :

Une identité publique ne devrait pas dépendre du compte personnel de :

L'infrastructure institutionnelle appartient à l'institution.

32.52Continuité de l'adresse courriel

L'adresse courriel municipale fonctionne souvent comme :

La ville devrait comprendre:

Un changement de fournisseur de courriel ne devrait pas effacer l'historique municipal.

32,53 Authentification à plusieurs facteurs

Les systèmes et les comptes administratifs importants devraient utiliser des contrôles d'authentification renforcés conformément aux directives professionnelles en matière de cybersécurité.

Les mesures exactes évolueront avec le temps.

Le principe ne devrait pas:

Une seule mot de passe volé ne devrait pas déverrouiller automatiquement un système essentiel de la ville.

32,54 Privilège administratif

Tous les employés ne devraient pas avoir:

accès.

Utiliser:

le privilège nécessaire minimum.

L'accès devrait suivre:

Quand quelqu'un change d'emploi:

Mettre à jour l'accès.

32,55 Employés qui quittent

Le processus de départ numérique devrait être aussi routinier que la collecte de:

Quand un employé ou un contractant quitte:

Un ancien employé ne devrait pas demeurer un administrateur invisible six mois plus tard.

32,56 Accès des contractants

Les entreprises de soutien extérieur peuvent légitimement avoir besoin d'accès au système.

La ville devrait savoir:

L'accès pour soutien devrait être temporaire et limité, même si c'est plus facile.

32,57 La sauvegarde est la souveraineté

Si la seule copie d'informations critiques d'Owen Sound existe dans le système actif du fournisseur, la ville dépend fortement de ce fournisseur.

Les systèmes importants nécessitent des stratégies de sauvegarde appropriées.

L'architecture peut varier.

L'objectif est:

Une panne à un endroit ne doit pas effacer le dossier public ou le service public.

32,58 Indépendance des sauvegardes

Pour les systèmes critiques, demander si les sauvegardes sont suffisamment indépendantes pour que la même:

ne puisse détruire à la fois les données primaires et toutes les sauvegardes.

La conception technique relève des professionnels.

Le conseil devrait exiger que la question ait été répondue.

32,59 Tests de restauration

Une sauvegarde devrait être testée périodiquement par une restauration réelle, si applicable.

La question utile n'est pas:

Avons-nous des sauvegardes?

C'est:

Pouvons-nous restaurer le service à partir d'elles?

32.60Objectifs de reprise

Des systèmes différents peuvent tolérer des temps d'arrêt différents.

Pour chaque service important, déterminez des objectifs professionnels de reprise.

Un système de réservation récréative peut tolérer un temps d'arrêt plus long qu'un système essentiel à:

Investissez les ressources de résilience en conséquence.

32.61Continuité manuelle

Pour les services publics essentiels, maintenez des méthodes raisonnables pour continuer à fonctionner lorsque les systèmes numériques échouent.

Des exemples peuvent inclure:

Le processus manuel peut être plus lent.

Cela est acceptable.

La continuité signifie que le service ne disparaît pas.

32.62Maturité en cybersécurité

Owen Sound devrait évaluer périodiquement sa maturité en cybersécurité selon un cadre professionnel approprié.

La réglementation actuelle sur la cybersécurité de 2026 en Ontario, pour les entités du secteur public qu'elle prescrit actuellement, utilise des concepts d'évaluation formelle de la maturité en cybersécurité et de signalement d'incidents. Les municipalités ne sont pas actuellement prescrites par cette réglementation, mais le modèle fournit une indication utile de l'orientation évolutive du secteur public provincial.

Owen Sound ne devrait pas attendre une crise pour se demander:

À quel point sont matures nos contrôles?

32.63Responsabilité au niveau supérieur

La cybersécurité devrait avoir un responsable administratif de haut niveau clairement identifié.

Cela ne nécessite pas automatiquement la création d'un autre poste exécutif.

Quelqu'un doté d'une autorité suffisante doit être responsable d'assurer:

Aucun système ne devrait dépendre de:

J'avais cru que les TI s'en chargeaient.

32.64Surveillance par le conseil municipal

Le conseil municipal n'a pas besoin:

Il a besoin de comprendre:

La gouvernance exige suffisamment d'information pour prendre des décisions sur le budget et les risques sans publier des instructions d'attaque.

32.65Registre des risques en cybersécurité

Maintenez un registre interne protégé des risques technologiques importants.

Exemples:

Donnez à chaque risque important:

Le risque qui n'est pas attribué à personne reste généralement un risque.

32.66Inventaire des actifs

La cybersécurité commence par connaître ce qui existe.

Maintenez un inventaire approprié de :

Vous ne pouvez pas corriger quelque chose que vous avez oublié d'exister.

32.67Technologie fantôme

Les employés peuvent parfois adopter un logiciel parce qu'il résout rapidement un problème.

Cela peut créer des systèmes que la ville ne sait pas contenir :

Rendez la technologie approuvée suffisamment facile à utiliser pour que le personnel ne se sente pas obligé d'utiliser des solutions de contournement non sécuritaires.

Établissez ensuite des règles claires pour les nouveaux outils.

32.68Systèmes hérités

Le logiciel ancien peut continuer à fonctionner longtemps après la fin de :

ces services.

Maintenez une liste des systèmes hérités.

Pour chacun :

« Il fonctionne encore » n'est pas une stratégie de cycle de vie.

32.69Maintenance préventive numérique

La technologie a besoin d'une maintenance préventive, tout comme :

Exemples :

Un budget municipal devrait reconnaître ces besoins récurrents.

32.70Dette numérique

Reporter la maintenance crée une dette numérique.

La ville peut économiser de l'argent pendant un an en différant :

Au final, le problème accumulé devient :

Suivez la dette numérique en parallèle avec les risques liés aux infrastructures physiques.

32.71Technologie opérationnelle

Les systèmes associés à l'infrastructure municipale physique méritent une attention particulière.

La technologie utilisée autour de :

peut avoir des conséquences au-delà de la perte de fichiers.

Les orientations du Centre en matière de cloud et de gestion des risques mettent l'accent sur le risque de cycle de vie, la continuité et les contrôles de sécurité, des principes qui deviennent encore plus importants lorsque les systèmes numériques soutiennent des opérations physiques.

Les systèmes opérationnels devraient être examinés conformément aux normes professionnelles adaptées à l'infrastructure réelle.

32.72Séparer lorsqu'il est nécessaire

Les systèmes opérationnels essentiels peuvent nécessiter une séparation plus forte par rapport à :

L'architecture technique relève des spécialistes qualifiés.

La règle de la politique est :

La commodité ne doit pas relier des systèmes que la sécurité exige de séparer.

32.73L'eau ne doit pas dépendre d'un seul mot de passe

Les systèmes municipaux essentiels ne devraient pas présenter d'éléments évidents tels que :

des points de défaillance où des mesures de protection raisonnables pourraient les éliminer.

La résilience est un ensemble de couches.

32.74Systèmes financiers

Le logiciel financier devrait protéger :

Les contrôles devraient inclure des éléments appropriés tels que :

La commodité du logiciel ne doit pas éliminer le contrôle financier.

32.75Systèmes de paiement

Si la ville change de prestataire de paiement, les résidents ne devraient pas perdre l'accès aux services municipaux.

Comprendre :

Cela s'inscrit dans le travail sur le coût des paiements dans Shop Local.

32.76Registres

Un registre municipal peut devoir rester disponible plus longtemps que le logiciel utilisé pour le créer.

La stratégie de gestion des registres devrait donc être séparée conceptuellement de la durée de vie du logiciel.

Un registre créé en 2027 peut encore être pertinent lorsque l'application 2027 n'existe plus.

Préserver le registre.

Pas nécessairement le logiciel obsolète.

32.77Cartes et SIG

Les informations géographiques peuvent devenir l'une des ressources numériques les plus précieuses de la ville.

La ville devrait conserver le contrôle des données géographiques publiques essentielles suffisamment pour pouvoir :

Un fournisseur de cartographie peut changer.

La connaissance géographique d'Owen Sound devrait rester.

32.78Site Web public

Le site Web de la ville est une porte d'entrée publique essentielle, même s'il n'est pas une infrastructure critique au même sens que l'eau.

La ville devrait contrôler :

Un redéploiement du site Web ne devrait pas effacer :

sans plan de migration.

32.79Les réseaux sociaux ne sont pas une infrastructure souveraine

Les plateformes sociales peuvent être des canaux de distribution précieux.

Elles ne devraient pas être la seule plateforme pour :

Si une plateforme sociale suspend le compte de la Ville demain :

Le système d'information publique devrait continuer à fonctionner.

32.80Intelligence artificielle

L'intelligence artificielle crée une nouvelle version de la même question de souveraineté.

Un employé de la Ville peut entrer des informations dans un système d'intelligence artificielle.

La réponse peut être générée par :

La première question ne devrait pas être :

L'intelligence artificielle peut-elle le faire ?

Elle devrait être :

Quelles informations, décisions et dépendances l'utilisation de l'intelligence artificielle crée-t-elle ?

32.81Cadre de l'intelligence artificielle en Ontario

La Loi sur l'amélioration de la sécurité numérique et la confiance en Ontario établit un cadre au moyen duquel des exigences concernant l'intelligence artificielle dans le secteur public peuvent être prescrites, notamment des dispositions sur la transparence, la responsabilisation, la gestion des risques et la surveillance humaine dans les circonstances prescrites.

Cela rend sensé que Owen Sound élabore maintenant son propre inventaire et ses pratiques de gouvernance en matière d'intelligence artificielle, tout en faisant soigneusement la distinction entre les exigences juridiques municipales actuelles et celles qui pourraient s'appliquer uniquement lorsqu'elles sont prescrites.

32.82Inventaire de l'intelligence artificielle

La Ville devrait connaître les systèmes d'intelligence artificielle importants qu'elle utilise.

L'inventaire pourrait inclure :

Ne tentez pas de cataloguer chaque fonction de vérification orthographique comme un système d'intelligence artificielle majeur.

Concentrez-vous sur les usages qui affectent matériellement :

32.83Intelligence artificielle à faible risque

Des exemples peuvent inclure l'assistance pour :

Ces usages nécessitent quand même :

mais peuvent justifier une gouvernance plus légère.

32.84Intelligence artificielle à plus haut risque

Une surveillance plus rigoureuse devrait s'appliquer lorsque des outils automatisés influencent des questions impliquant :

Plus les conséquences sont élevées :

Plus la surveillance humaine doit être forte.

32.85L'intelligence artificielle ne reçoit pas d'autorité publique

Un modèle logiciel ne devrait pas exercer indépendamment un pouvoir coercitif municipal simplement parce qu'il peut produire une recommandation.

L'IA peut aider le personnel à :

Un être humain responsable ou un processus légalement autorisé reste chargé des décisions nécessitant :

32.86Aucune dénégation en boîte noire

Un résident ne devrait pas recevoir :

Demande refusée par un algorithme

sans explication significative lorsque la décision exige légalement ou pratiquement un raisonnement humain responsable.

Le critère des motifs publics établi précédemment s'applique toujours.

La technologie n'élimine pas la justice procédurale.

32.87L'IA et les renseignements personnels

Avant de placer des renseignements sur les résidents dans un service d'IA, déterminer :

Ne pas supposer qu'une boîte de chat d'IA est équivalente à un document interne de la Ville.

32.88Aucune donnée sensible dans une IA non approuvée

Les employés et les participants au Corps civique devraient recevoir une règle claire :

Ne pas placer des renseignements protégés sur les résidents ou municipaux dans un service d'IA public non approuvé.

La formation devrait expliquer pourquoi.

Une politique que les employés comprennent est plus utile qu'un interdit de vingt pages que personne ne lit.

32.89Dispositions sur la formation à l'IA

Lorsque la Ville achète un service doté d'une IA, les contrats devraient préciser si les renseignements de la Ville peuvent être utilisés pour :

les modèles du fournisseur.

La réponse appropriée peut varier selon le système.

Elle ne devrait pas rester inconnue.

32.90Conservation des invites

Les fournisseurs d'IA peuvent conserver :

selon la conception du service et le contrat.

La Ville devrait comprendre ces pratiques avant d'utiliser le service pour des travaux municipaux.

La conservation est toujours une conservation même lorsque l'interface semble conversationnelle.

32.91Précision de l'IA

L'IA générative peut produire :

information.

L'utilisation municipale devrait exiger une vérification des sources appropriées pour les sorties importantes.

La règle est :

L'IA peut rédiger la réponse. Une personne responsable est responsable de la réponse.

32.92L'IA et les sources

Lorsque l'IA est utilisée pour aider à répondre à une question municipale factuelle d'un résident, le système devrait idéalement renvoyer à la source autoritative :

Le résident devrait pouvoir vérifier.

32.93Traduction par l'IA

La traduction par l'IA pourrait rendre l'information municipale plus accessible.

Pour les communications importantes :

utilisez un niveau approprié de vérification humaine.

La facilité de traduction ne doit pas créer une confiance fausse envers la précision.

32.94Sortie du fournisseur d'IA

Posez la même question de souveraineté aux fournisseurs d'IA :

Que se passera-t-il si ce modèle disparaît ?

La ville peut-elle :

Ne construisez pas un service municipal essentiel autour d'un seul modèle propriétaire sans comprendre la sortie.

32.95Indépendance du modèle

Là où c'est pratique, l'architecture du système devrait séparer :

de tout modèle d'IA particulier.

Ainsi, le modèle sous-jacent pourra éventuellement être remplacé.

Concevoir pour la substitution crée un levier.

32.96Logiciels open source

Le logiciel open source peut parfois offrir :

Il peut aussi créer des responsabilités en matière de :

.

La ville devrait évaluer le logiciel open source sur la base de :

Pas sur l'idéologie.

32.97Le logiciel open source ne signifie pas gratuit

Le coût de la licence logicielle peut être nul.

Le coût d'exploitation peut inclure :

Comparez le coût complet.

32.98Le logiciel propriétaire ne signifie pas mauvais

Le logiciel propriétaire commercial peut offrir :

La question de souveraineté demeure :

Pouvons-nous récupérer nos données ?

Pouvons-nous continuer à offrir le service public si cette relation change ?

32.99Construire versus acheter

Pour chaque besoin numérique important, envisagez :

Acheter

Quand des produits matures résolvent déjà le problème de manière efficace.

Construire

Quand la demande est suffisamment unique pour justifier la propriété et le développement.

Partenariat

Quand une autre organisation publique a le même besoin.

Logiciel libre

Quand une solution communautaire existante offre une valeur forte.

Ne construisez pas simplement parce que construire semble innovant.

N'achetez pas simplement parce que c'est plus facile ce mois-ci.

32.100Technologie municipale partagée

De nombreuses municipalités canadiennes résolvent des problèmes similaires.

Elles ont toutes besoin de versions de :

Owen Sound devrait explorer s'il est possible de :

C'est un chemin vers la capacité numérique canadienne.

32.101Partenariat avec le comté de Grey

Avant de dupliquer une technologie majeure, demandez-vous :

Le comté de Grey exploite-t-il déjà quelque chose que nous pouvons légalement et pratiquement partager ?

De même :

Owen Sound pourrait-il créer quelque chose que le comté et les municipalités voisines pourraient réutiliser ?

L'infrastructure numérique peut traverser plus facilement les limites municipales que l'infrastructure physique.

32.102Achat partagé

Plusieurs municipalités peuvent parfois bénéficier de :

par l'achat collaboratif.

Cela nécessite :

L'achat partagé ne devrait pas créer un système régional encore plus difficile à quitter.

Appliquez le Test de sortie au niveau partagé aussi.

32.103Manuel ouvert municipal canadien

Quand Owen Sound développe quelque chose d'utile :

publiez des versions réutilisables là où c'est légalement approprié.

Une petite municipalité ailleurs au Canada ne devrait pas avoir à réinventer la même gouvernance à partir de zéro.

32.104La souveraineté numérique est plus vaste que map.ca

La proposition map.ca n'est qu'un exemple.

Le principe s'applique également à :

Aucune plateforme ne reçoit d'exemption parce que la Ville préfère :

Les mêmes questions s'appliquent.

32.105map.ca Doit Réussir le Test le Plus Difficile

Puisque map.ca est associé à la personne qui propose ce plan, toute considération municipale future devrait faire face à un examen particulièrement rigoureux.

Le système devrait devoir démontrer :

L'objectif public prime.

32.106Aucune Dépendance au Fondateur

Une plateforme ne peut pas être une véritable infrastructure publique si elle dépend de manière permanente de :

Appelez Mike. Il sait comment cela fonctionne.

Si map.ca ou tout système associé est un jour transféré à un fonctionnement public :

Le fait que le fondateur ne soit plus nécessaire au fonctionnement quotidien est un signe d'institutionnalisation réussie.

32.107Aucun Veto du Fondateur

L'infrastructure publique ne peut rester soumise à une approbation privée concernant :

Une fois gérée publiquement, la gouvernance publique décide.

Cela demeure vrai même si le fondateur est fortement en désaccord.

32.108Aucune Royauté Cachée

Toute rémunération continue :

liée à une plateforme publique doit être divulguée et examinée indépendamment.

Le modèle d'intérêt public le plus clair est celui où les résidents peuvent voir que l'adoption publique n'a pas créé un profit politique privé.

32.109map.ca Ne Doit Pas Être Obligatoire

Les résidents ne devraient pas avoir besoin d'un compte map.ca pour :

Si map.ca fournit finalement des fonctionnalités utiles :

C'est bien.

L'accès municipal essentiel exige quand même des alternatives appropriées.

L'infrastructure publique devrait réduire la dépendance.

Et non en créer une nouvelle.

32.110La Question d'Identité Publique

Si les résidents reçoivent finalement des identités ou adresses numériques permanentes par un système d'intérêt public, ces identités devraient être :

La Ville ne devrait pas créer un compte qui devient un dossier universel des :

Une intégration pratique peut devenir une concentration dangereuse.

32.111Séparer les données selon leur objectif

Même lorsque une seule porte d'entrée publique permet l'accès à plusieurs services, les informations sous-jacentes devraient rester régies par leur objectif.

Une inscription pour les loisirs n'a pas besoin de se combiner à :

Une seule porte d'entrée

n'exige pas

un seul profil énorme.

32.112Connexions contrôlées par le résident

Là où différents services peuvent être connectés, le résident devrait comprendre :

La conception technique la plus pratique n'est pas toujours la meilleure conception civique.

32.113Souveraineté numérique des résidents

La souveraineté numérique municipale devrait finalement soutenir la souveraineté numérique personnelle également.

Les résidents devraient de plus en plus comprendre :

Une communauté souveraine numériquement commence par des citoyens compétents.

32.114Défi des jeunes

Les jeunes devraient être invités à participer à ce travail.

Demandez aux participants du Corps civique :

Si Owen Sound devait remplacer ce service demain, comment le ferions-nous ?

Cela enseigne :

Cela invite également une génération élevée à l'intérieur des plateformes numériques à remettre en question les dépendances que les adultes ne remarquent plus.

32.115Apprentissage numérique

Le Corps civique pourrait finalement soutenir des opportunités d'apprentissage rémunérées impliquant :

Les étudiants travaillent sous la supervision qualifiée.

Ils n'obtiennent pas un accès illimité aux systèmes sensibles simplement parce qu'ils sont techniquement doués.

32.116Éducation technologique canadienne

Les écoles, les collèges, les entreprises et les partenaires du Corps civique peuvent exposer les jeunes à :

L'objectif n'est pas :

Arrêter d'utiliser la technologie étrangère.

C'est :

Développer suffisamment de compétences canadiennes pour avoir des choix.

32.117La souveraineté vient aussi des compétences

Acheter un logiciel canadien sans travailleurs canadiens capables de :

n'offre pas d'autonomie durable.

Investir dans les personnes.

Un pays capable de concevoir et d'entretenir des systèmes a plus d'options qu'un pays qui n'est capable que de les acheter.

32.118Innovation locale

Le rôle de la ville peut inclure la création d'opportunités appropriées pour que les entreprises locales et les étudiants résolvent des défis publics définis.

Exemple :

Est-ce que quelqu'un peut créer une méthode ouverte pour publier cet ensemble de données ?

Ensuite, utiliser des règles d'approvisionnement ou de concours équitables.

L'innovation devrait être :

Pas :

32.119Environnements de test publics

Lorsque cela est pratique, créer des environnements non productifs sécurisés pour :

Ne pas donner l'accès au code expérimental à :

L'innovation a besoin d'un espace de test.

Le service public a besoin de protection.

32.120Ne pas construire un centre de données municipal pour la gloire

L'autonomie numérique ne devrait pas être utilisée pour justifier la construction d'un établissement coûteux d'hébergement informatique simplement parce que :

Alors, nous possédons les serveurs.

Avant toute infrastructure d'hébergement locale :

La possession physique peut créer une dépendance nouvelle envers l'expertise locale et le capital.

L'objectif est un service résilient.

Pas une pièce pleine de lumières clignotantes.

32.121Utiliser d'abord la capacité existante

Avant toute nouvelle infrastructure, examiner :

La meilleure solution autonome peut être contractuelle et architecturale.

Pas une construction physique.

32.122Redondance géographique

Pour des systèmes vraiment critiques, garder toutes les copies dans un seul bâtiment peut être moins résilient qu'une infrastructure appropriée et répartie géographiquement.

L'autonomie ne devrait pas être confondue avec :

Tout ce qui se trouve à côté du bureau du maire.

Une inondation, un incendie ou une panne peuvent affecter l'infrastructure locale aussi.

La résilience peut exiger une séparation géographique.

32.123Résilience de la chaîne d'approvisionnement

Les matériels technologiques dépendent des chaînes d'approvisionnement mondiales.

Owen Sound ne fabriquera pas :

La souveraineté numérique ne signifie donc pas l'autosuffisance totale.

Cela signifie comprendre lesquelles des dépendances nécessitent :

La résilience pratique l'emporte sur l'indépendance impossible.

32.124Pièces de rechange critiques

Pour les infrastructures sélectionnées, il est important de maintenir :

afin de réduire les temps d'arrêt.

Le stockage devrait suivre :

Ne stockez pas de technologies coûteuses qui deviendront obsolètes avant d'être nécessaires.

32.125Exercice de panne du fournisseur

Pour les fournisseurs critiques, demandez périodiquement :

Que se passerait-il si ce fournisseur n'était pas disponible pendant un jour ?

Une semaine ?

Effectuez des exercices de table de situation lorsque la conséquence le justifie.

L'objectif n'est pas de prédire chaque panne.

C'est d'identifier la première dépendance évidente avant la panne réelle.

32.126Exercice annuel de sortie

Pour un système majeur sélectionné chaque année, effectuez une revue pratique de souveraineté.

Tentez de :

Demandez :

Est-ce que nous pourrions vraiment partir ?

Cela transforme la sortie d'un fournisseur d'un paragraphe dans un contrat en un fait opérationnel.

32.127Revue avant renouvellement

Avant de renouveler une technologie importante, évaluez :

Performance

Fonctionne-t-elle ?

Coût

Est-ce toujours une bonne valeur ?

Sécurité

Le risque est-il acceptable ?

Confidentialité

Les informations sont-elles traitées de façon appropriée ?

Portabilité

Pouvons-nous partir ?

Résilience canadienne

Y a-t-il des dépendances juridictionnelles ou d'approvisionnement à changer ?

Expérience utilisateur

Est-ce que cela sert bien les citoyens et le personnel ?

Un fournisseur à longue durée d'utilisation ne devrait pas recevoir un renouvellement automatique simplement parce que le changement est inconfortable.

32.128Réserves technologiques

Les remplacements numériques importants devraient être planifiés sur le plan financier.

Une municipalité qui sait :

Ce système majeur aura probablement besoin d'être remplacé dans quatre ans

devrait commencer à budgétiser avant l'urgence.

Le remplacement numérique appartient à la planification à long terme des immobilisations et des dépenses de fonctionnement, tout comme les actifs physiques.

32.129Éviter l'augmentation des abonnements

Les petits abonnements logiciels peuvent se multiplier.

Une fois par an, passez en revue :

Demandez :

Est-ce que nous payons trois entreprises pour effectuer essentiellement la même tâche ?

Annulez ce qui n'est pas nécessaire.

L'efficacité s'applique aussi en ligne.

32.130Utilisation des permis

Pour les logiciels majeurs sous abonnement :

peut aider à identifier le gaspillage.

N'utilisez pas la surveillance des employés pour déterminer la productivité.

Mesurez si le permis lui-même est nécessaire.

32.131Baromètre de souveraineté numérique

Le baromètre public devrait inclure des mesures élevées et sécurisées.

Systèmes

Contrats

Portabilité

Sauvegarde

Héritage

Capacité canadienne

Cybersécurité

Confidentialité

IA

Coût

N'exposez pas les vulnérabilités simplement pour rendre le tableau détaillé.

32.132Évaluation du risque de souveraineté

Chaque système critique peut avoir une évaluation interne du risque de souveraineté.

Facteurs possibles :

Un score faible ne signifie pas :

Le fournisseur est mauvais.

Cela signifie :

Une dépendance nécessite une attention particulière.

32.133Publier le problème, protéger la vulnérabilité

Le public peut être informé de la manière suivante :

Trois systèmes critiques nécessitent un plan d'exit fournisseur amélioré.

Le public n'a pas besoin :

Voici les systèmes exactement non corrigés et les points d'accès administrateur.

La transparence et la sécurité ne sont pas des ennemis.

Une bonne gouvernance sait ce qui appartient à chaque catégorie.

32.134Premiers 100 jours

Les premiers 100 jours devraient établir la base.

1. Inventaire des systèmes numériques

Identifier les systèmes municipaux importants :

2. Revue d'importance critique

Classer les systèmes selon la conséquence du service.

3. Calendrier des contrats

Cartographier :

4. Carte des données

Identifier quels systèmes majeurs contiennent :

informations.

5. Carte des dépendances fournisseuses

Identifier les dépendances majeures en matière d'hébergement, d'identité et de soutien.

6. Revue des sauvegardes et de la récupération

Demander si les systèmes critiques peuvent effectivement être restaurés.

7. Revue de portabilité

Choisir plusieurs systèmes importants et tester si les données peuvent être exportées utilement.

8. Inventaire de l'IA

Identifier l'IA matérielle actuellement utilisée par la ville et établir une règle provisoire d'utilisation par les employés.

Confirmer les obligations actuelles en vertu de :

10. Publier un rapport de base sécurisé

Ne pas publier les détails des attaques.

Présenter :

32.135Première année

Au cours de la première année :

L'objectif n'est pas de remplacer tout.

Il est de savoir sur quoi nous dépendons.

32.136Deuxième année

Pendant la deuxième année :

32.137Troisième année

Pendant la troisième année :

Si les preuves soutiennent un projet d'infrastructure communautaire ou partagée :

Présenter le dossier complet au conseil municipal.

Ne pas le construire simplement parce que la troisième année est arrivée.

32.138Quatrième année

D'ici la quatrième année, Owen Sound devrait être en mesure de répondre aux questions suivantes :

Savons-nous chaque grand système numérique sur lequel nous dépendons ?

Savons-nous ce que chacun coûte ?

Savons-nous quand chaque contrat expire ?

Savons-nous où l'information importante est stockée ?

Comprenons-nous les principales dépendances étrangères et nationales ?

Pouvons-nous exporter nos informations ?

Avons-nous testé cette exportation ?

Les systèmes critiques peuvent-ils être restaurés ?

Les systèmes importants ont-ils des plans de continuité ?

Les systèmes obsolètes non soutenus sont-ils en baisse ?

Savons-nous quels systèmes d'IA affectent matériellement les opérations publiques ?

L'information sensible est-elle protégée contre une utilisation inappropriée d'IA ?

Les fournisseurs canadiens ont-ils eu des opportunités équitables ?

Avons-nous partagé des pratiques technologiques municipales utiles avec d'autres communautés ?

Owen Sound pourrait-il quitter ses fournisseurs les plus importants sans perdre le service public lui-même ?

La dernière question est le cœur de toute cette section.

32.139À quoi le succès ressemble-t-il ?

Le succès ne signifie pas :

Owen Sound possède chaque serveur.

Le succès signifie :

Owen Sound possède ses décisions.

Cela signifie que la ville peut dire à un fournisseur de technologie :

Nous aimerions continuer à travailler avec vous car vous offrez une bonne valeur.

Et non :

Nous n'avons pas d'option réaliste d'autre que de rester.

Cela signifie :

C'est la souveraineté.

32.140Ce que cela n'est pas

La souveraineté numérique canadienne n'est pas :

Il s'agit d'une indépendance pratique.

L'engagement à la souveraineté numérique canadienne

L'infrastructure numérique détermine de plus en plus si le gouvernement lui-même peut fonctionner.

Le public devrait donc savoir que les informations de la ville et les services essentiels ne peuvent pas devenir silencieusement la propriété permanente d'une relation logicielle.

L'engagement est le suivant :

Définir la souveraineté numérique comme un contrôle pratique, et non une isolement technologique.

Commencer chaque décision technologique par le service public plutôt que par le logiciel.

Classifier les systèmes numériques selon leurs conséquences réelles.

Créer un index des systèmes numériques.

Savoir qui détient chaque système important en interne.

Savoir qui sont les fournisseurs majeurs et les dépendances de la chaîne d'approvisionnement.

Demander comment on peut quitter un système avant de signer un contrat.

Tester si les informations exportées sont réellement utilisables.

Privilégier les normes ouvertes et interoperables lorsqu'elles offrent une bonne valeur.

Documenter les systèmes personnalisés.

Protéger contre la dépendance à une seule personne.

Utiliser la technologie en nuage là où cela a du sens.

Héberger soi-même là où cela a du sens.

Ne pas traiter l'une ou l'autre approche comme une idéologie.

Savoir où sont stockées et traitées les données sensibles.

Reconnaître que la résidence des données canadiennes et le contrôle juridique canadien sont des questions liées mais non identiques.

Accorder aux fournisseurs canadiens de technologies compétents une opportunité équitable dans le cadre de la loi.

Évaluer chaque fournisseur sur la base de la sécurité, de la résilience, de la valeur sur le cycle de vie et de la sortie.

Minimiser les renseignements personnels recueillis par le gouvernement.

Protéger les systèmes d'identité comme infrastructure essentiiel.

Assurer une récupération indépendante et testée des informations critiques.

Tester la restauration, et non seulement la sauvegarde.

Maintenir une continuité manuelle raisonnable pour les services essentiels.

Identifier et réduire la technologie héritée non soutenue.

Considérer l'entretien numérique comme l'entretien d'infrastructures.

Identifier la dette numérique plutôt que de la laisser devenir une urgence.

Protéger les systèmes opérationnels soutenant l'infrastructure physique.

Établir un inventaire des usages significatifs de l'intelligence artificielle.

Assurer que des humains responsables soient tenus responsables des décisions publiques importantes.

Jamais ne placer d'informations sensibles des résidents dans des systèmes d'IA publics non approuvés.

Comprendre si un fournisseur d'IA utilise les informations municipales pour l'entraînement.

Concevoir des systèmes d'IA de manière à ce que le modèle sous-jacent puisse être modifié là où c'est pratique.

Évaluer les technologies open source et propriétaires sur la base de leur valeur sur le cycle de vie complet.

Partager les systèmes numériques municipaux utiles et les outils de gouvernance avec d'autres communautés canadiennes.

Collaborer avec le comté de Grey lorsque l'infrastructure partagée est plus logique que la duplication.

Ne construisez jamais un établissement serveur uniquement pour donner l'apparence d'une indépendance.

Développez les compétences canadiennes ainsi que la technologie canadienne.

Offrez aux jeunes des voies pratiques vers la cybersécurité, les données et la technologie civique.

Appliquez le même test de souveraineté à map.ca que celui que nous appliquons à chaque autre fournisseur.

N'accordez aucun contrôle permanent à un fondateur privé sur l'infrastructure numérique publique.

Ne servez jamais un seul portail public pratique pour créer un profil de surveillance des résidents de grande envergure.

Examinez les grandes technologies avant leur renouvellement plutôt qu'après leur verrouillage.

Effectuez des exercices réels de sortie des fournisseurs et de récupération.

Publiez la gouvernance sans publier la vulnérabilité.

Une ville souveraine n'a pas besoin de produire tout elle-même.

Elle doit savoir qu'elle peut encore se gouverner elle-même lorsque la technologie change.

Propriétéz l'objectif public. Contrôlez l'information publique. Comprenez les dépendances. Conservez la capacité de quitter. Développez la capacité canadienne là où elle nous rend plus forts. N'allowez jamais que la commodité devienne silencieusement une captivité.

← Chapitre 31: Le Programme d'information sécuriséeChapitre 33: map.ca comme infrastructure publique →