Secteurs

Azure et IA pour le secteur public

Les projets du secteur public échouent pour des raisons qui n’ont rien de technique : la personne qui achète n’est pas celle qui utilise, le budget meurt le 31 mars, et ce qui est livré doit être exploité par une équipe de quatre pendant dix ans. L’architecture doit répondre aux trois.

Trois contraintes propres au secteur

L’acheteur n’est pas l’utilisateur, et aucun des deux ne l’exploitera. L’approvisionnement note une proposition, un responsable de programme a besoin du service, et une petite équipe interne en hérite au départ du fournisseur. Le mode d’échec classique : un environnement qu’un seul fournisseur sait exploiter, découvert au renouvellement suivant, quand le prix a bougé et qu’il n’existe pas d’alternative réaliste. Le transfert n’est pas une formalité de clôture ici. C’est l’exigence qui doit façonner l’architecture dès le premier jour : infrastructure comme code dans votre dépôt, services standards plutôt qu’astucieux, procédures écrites pour l’équipe qui existe réellement.

L’exercice financier est une contrainte d’architecture. Les budgets ne se reportent pas, la portée est figée au moment de l’appel d’offres, et un changement de portée est un avenant au contrat, pas un billet. Le travail doit être découpé en tranches qui livrent chacune quelque chose d’utilisable à l’intérieur de leur propre période de financement, et chaque tranche doit laisser le parc dans un état cohérent si la suivante n’est jamais financée. Concevoir une plateforme sur trois ans qui ne produit de valeur qu’en troisième année, c’est la faire annuler en deuxième.

Tout ce que vous construisez est communicable, et tout le monde doit pouvoir s’en servir. Une demande d’accès à l’information peut atteindre les documents d’architecture, le contrat et le registre d’incidents. L’accessibilité est une obligation, pas une intention, et elle vise les outils internes autant que les services aux citoyens. Les deux poussent dans le même sens : écrire clairement, construire selon WCAG 2.1 AA, et éviter tout composant dont vous auriez du mal à expliquer le comportement en public.

Ce que nous construisons ici

  • Une landing zone où la résidence est imposée, pas affirmée. Groupes d’administration, distribution d’abonnements par programme ou par direction, et Azure Policy qui refuse tout déploiement hors des régions autorisées. La landing zone Azure est livrée en Terraform dans votre propre dépôt, avec les pipelines qui la déploient, pour que le prochain fournisseur hérite d’un système et non d’une énigme.
  • Une identité qu’un vérificateur peut lire. Microsoft Entra ID avec accès conditionnel, Privileged Identity Management pour que personne ne détienne de droits d’administration permanents, revues d’accès planifiées, et gouvernance des comptes invités pour les sous-traitants et les organismes partenaires avec qui vous travaillez tous les jours. C’est la substance de la cybersécurité et Entra ID.
  • La consolidation de ce qui s’est accumulé. Locataires de direction, abonnements orphelins et serveurs de fichiers jamais réconciliés depuis une réorganisation, cartographiés par analyse de dépendances et déplacés par vagues avec la migration Azure, chaque vague ayant son propre chemin de retour arrière.
  • De la preuve et de la surveillance dimensionnées pour un budget public. Posture Defender for Cloud, Azure Monitor, et Microsoft Sentinel avec une ingestion conçue délibérément, parce qu’une ingestion de journaux non maîtrisée est la ligne budgétaire qui fait couper un programme de sécurité. La correspondance avec les contrôles et l’export des preuves relèvent de l’architecture de conformité.
  • De l’IA là où elle est défendable. Document Intelligence sur les formulaires et les demandes qui circulent encore sur papier, et recherche sur vos propres directives et procédures avec permissions conservées et citations affichées. Notre ingénierie IA commence par ce que le système n’a pas le droit de faire, écrit avant que rien ne soit construit.

Scénario anonymisé

Scénario anonymisé, pas un client nommé.

Un organisme public d’environ 900 personnes exploite deux salles de serveurs, un inventaire applicatif jamais réconcilié depuis une réorganisation, et une équipe d’infrastructure de quatre personnes qui se partagent la garde. Une directive ministérielle exige de démontrer l’hébergement des données au Québec. La soumission pour le renouvellement du matériel est arrivée le même mois.

Ce que le mandat produit est peu spectaculaire et durable. Une cartographie de dépendances qui nomme enfin les douze applications que personne ne pouvait expliquer, dont trois n’ont aucun utilisateur. Une hiérarchie de groupes d’administration avec politique de région, pour que la résidence soit imposée par refus et que le refus soit journalisé. Une migration par vagues alignées sur les périodes de financement, chaque vague laissant un parc cohérent derrière elle. Les accès privilégiés passés en élévation temporaire, ce qui fait disparaître les comptes d’administration permanents signalés deux fois par la vérification. Puis un transfert écrit : le Terraform, les pipelines, les procédures, et deux semaines de travail côte à côte avec l’équipe qui reprend, parce qu’un document jamais pratiqué n’est pas un transfert.

Le contexte réglementaire que nous prenons comme contrainte

La Loi sur l’accès aux documents des organismes publics et sur la protection des renseignements personnels, la Loi 25 et la surveillance de la Commission d’accès à l’information, y compris l’évaluation des facteurs relatifs à la vie privée exigée avant toute communication de renseignements personnels hors Québec. La Loi sur les contrats des organismes publics et le SEAO encadrent la façon dont le travail est acheté, donc la façon dont il doit être découpé. Les standards gouvernementaux d’accessibilité web, alignés sur WCAG, s’appliquent aux interfaces. Ailleurs au Canada, les lois provinciales d’accès et la Loi canadienne sur l’accessibilité. Lorsqu’un organisme achète d’un fournisseur qui doit lui-même être audité, SOC 2 Type II est l’instrument habituel. Nous concevons pour que chacune de ces obligations devienne un contrôle appliqué avec un enregistrement exportable, plutôt qu’un paragraphe dans une politique que personne ne peut vérifier.

Questions fréquentes

Comment acheter sans lancer un appel d’offres complet ?

Nos offres sont transigeables sur la Place de marché Azure, ce qui permet d’acheter contre une entente Microsoft existante plutôt que d’ouvrir un processus distinct. Quand un appel d’offres est requis, nous aidons à écrire des exigences vérifiables et neutres, y compris quand cela veut dire que nous ne le remportons pas.

Pouvez-vous garantir que nos données restent au Québec ?

Nous l’imposons plutôt que de le garantir, ce qui est plus solide. Les régions autorisées sont fixées par Azure Policy au niveau du groupe d’administration : un déploiement ailleurs est refusé, et la tentative est journalisée. Quand l’obligation est provinciale plutôt que canadienne, le même mécanisme s’applique avec une liste de régions plus étroite, et le journal fait la preuve.

Notre équipe TI compte quatre personnes. Qui exploite ça après ?

Vous, et c’est une contrainte de conception dès la première semaine, pas une réunion de transfert à la fin. L’infrastructure en code vit dans votre dépôt, les procédures sont écrites pour l’équipe qui existe, et nous évitons volontairement les patrons qui ne tiennent que si un spécialiste est de garde. Si vous préférez que nous l’exploitions, c’est une entente distincte que vous pouvez résilier.

L’accessibilité s’applique-t-elle aussi aux systèmes internes ?

Oui, et c’est l’exigence la plus souvent découverte à la recette. Nous construisons selon WCAG 2.1 AA sur toute interface, interne ou publique, parce qu’un membre du personnel qui utilise un lecteur d’écran relève de la même obligation qu’un citoyen, et parce que corriger une application après sa mise en ligne coûte plusieurs fois le prix de l’avoir bien faite.

Un organisme public peut-il utiliser l’IA générative de façon défendable ?

Dans des usages étroits et documentés. La recherche respecte les permissions existantes sur l’enregistrement source, les réponses citent le document d’origine, les requêtes et les réponses sont journalisées, l’inférence reste dans votre locataire, et une personne nommée demeure responsable de toute décision touchant un individu. Ce qui ne peut pas être expliqué à un demandeur en vertu de la loi sur l’accès ne devrait pas être déployé.

Amenez la charge de travail. Nous apportons l’architecture.

Trente minutes, un architecte, aucune présentation. Venez avec un problème, repartez avec un avis sur lequel agir.