Atténuer les risques liés aux projets gouvernementaux de technologie de l’information (TI)

Guide développé par le Service numérique canadien

Les Normes numériques du gouvernement du Canada (GC) fournissent un cadre utile pour le processus de remise en question, applicables aux services en ligne, aux systèmes administratifs et aux projets de TI en général. Parmi les autres documents de référence utiles, mentionnons 18F’s « De-risking government technology » guide et US DOD DIB Guide : Detecting Agile BS.

Ce guide est adapté des questions développées par 18F. On suggère aussi la liste des comportements alignés et non-alignés, développée par le Secteur du changement numérique du Bureau du dirigeant principal de l’information « Digital Standards In-Flight Check-in » (en cours d’être finalisée).

Bon nombre de ces questions peuvent être semblables à celles qui ont déjà été posées dans le cadre du processus de la fonction de remise en question. Le présent document a pour but de préciser les réponses qui pourraient être des causes de préoccupation (risque accru) ou de bons signes (risque atténué).

Concevoir avec les utilisateurs

1. De quoi l’utilisateur a-t-il besoin?
   • Causes de préoccupation : Tout ce qui n’indique pas clairement les besoins des utilisateurs finaux déterminés au moyen de la recherche sur la conception. Les initiatives répondent en grande partie aux « besoins opérationnels », sans offrir une idée claire de la façon dont les utilisateurs finaux tireront profit de ces initiatives.
   • Bon signe : Le Ministère a déterminé des besoins particuliers en se fondant sur des entrevues directes, des sondages ou d’autres commentaires auprès des utilisateurs finaux (les membres du public qui utiliseraient le service – et non les fonctionnaires qui agiraient comme des membres du public), et il peut nommer plusieurs de ces besoins en particulier.
   • Remarque : pour les services destinés au public (ou les projets de TI qui toucheront le public), les « besoins des utilisateurs » devraient inclure les besoins du public; étant donné que la plupart des systèmes touchent les fonctionnaires, les « besoins des utilisateurs » devraient aussi inclure leurs besoins; les besoins diffèrent des « besoins opérationnels », en se concentrant sur ce que les gens doivent faire, et non sur la façon dont ils pourraient le faire.
2. Quels résultats clairs, mesurables, à court et à moyen terme sont proposés pour les personnes qui utiliseront le service (ou le projet qui appuie un service)?
   • Causes de préoccupation : Tous les éléments de nature technique, au lieu d’améliorer l’expérience utilisateur. Objectifs liés à la mise en œuvre technique plutôt qu’aux résultats qui profitent aux utilisateurs finaux.
   • Bon signe : Un ou plusieurs résultats précis directement liés aux besoins des utilisateurs sont nommés.
3. Qui sont vos utilisateurs finaux, et comment allez-vous recueillir leurs commentaires et intégrer ceux-ci avant la première version pilote à petite échelle? À quelle fréquence effectuerez-vous des recherches de conception et des tests d’utilisabilité avec eux?
   • Causes de préoccupation : « Nous avons consulté les intervenants pour élaborer les exigences. » « Les exigences du projet sont déjà établies. » « Nous effectuerons des tests auprès du personnel interne. »
   • Bon signe : L’équipe peut repérer les différents groupes de personnes qui utiliseront l’initiative, y compris le public et les fonctionnaires, et donner des chiffres approximatifs pour chacun. L’équipe a des plans clairs concernant la recherche sur la conception et les tests d’utilisabilité auprès des utilisateurs finaux, ainsi qu’un calendrier et des processus pour intégrer continuellement la rétroaction dans l’élaboration du système ou du service.
4. Comment mesurera-t-on le succès et la fréquence? La mesure est-elle axée sur les résultats pour les utilisateurs plutôt que sur la conformité? Comment allez-vous recueillir des données pour cette évaluation? Les données sur le rendement seront-elles disponibles au grand public?
   • Causes de préoccupation : « La réussite est liée à l’achèvement de ce projet parce qu’il figurait dans notre plan d’investissement annuel. » « Nos paramètres de succès se situent dans un pourcentage proche de notre budget et de nos échéanciers initialement prévus. » « Nous ne pouvons pas recueillir les données sur le rendement pour des raisons de confidentialité. »
   • Bon signe : Une ou plusieurs mesures précises fondées sur l’expérience des utilisateurs du service, liées aux besoins des utilisateurs, et des étapes claires pour recueillir les données (par exemple : analyse sur le Web, taux de réussite et adoption de canaux en ligne, réponses aux formulaires de rétroaction, processus d’admission pour le centre d’appel ou personnel en personne pour transmettre la rétroaction des utilisateurs). Prévoir la façon dont les données sur le rendement seront publiées en temps réel ou fréquemment mises à jour.

Effectuer régulièrement des itérations et des améliorations

5. La taille et l’échelle de ce projet sont-elles susceptibles d’être réalisables? Quel est le coût et de quelle façon ce coût a-t-il été déterminé?
   • Causes de préoccupation : « Le coût correspond à notre enveloppe budgétaire. » « Le budget a été fixé il y a plusieurs années. »
   • Bon signe : « Le coût est inférieur à 20 millions de dollars. » « La mise en œuvre du projet prendra des mois et non des années. » « Nous avons divisé un grand projet en plusieurs projets de plus petite taille. »
   • Remarques : Ces questions sont probablement très semblables à celles déjà posées par la fonction de remise en question. L’accent est mis sur l’idée d’établir la portée des projets ayant une plus petite taille que ceux des initiatives de TI, encourageant ainsi les ministères à se concentrer sur la réalisation d’une valeur concrète plus hâtivement, donnant lieu à une meilleure gestion des dépenses dans le processus.
6. Combien de temps faudra-t-il entre le début du projet et le moment où les améliorations seront visibles et utilisables pour la première fois par le public? À quelle fréquence les modifications seront-elles apportées aux utilisateurs des systèmes?
   • Causes de préoccupation : « Lorsque le projet est terminé. » « À la fin. » « Dans plus de 6 mois. »
   • Bon signe : « Dans les 6 prochains mois. » « Continuer à partir du X, à mesure que des éléments individuels du projet sont achevés. »
7. Le Ministère a-t-il un plan pour avoir le bon mélange multidisciplinaire de talents nécessaires à l’élaboration et à la mise en œuvre de l’initiative? Ces équipes resteront-elles en place de façon continue pour soutenir le service de manière durable?
   • Causes de préoccupation : « Le personnel est affecté au projet pour la période d’élaboration seulement. » « Nous avons une équipe de projet spécialisée, mais les développeurs de logiciels sont en rotation à court terme à partir du groupe de TI central. » « Une fois le projet terminé, aucune autre modification ne sera nécessaire ou apportée. » « Nous embaucherons un fournisseur externe pour apporter des changements au besoin. »
   • Bon signe : « Nous avons une équipe multidisciplinaire en place qui est entièrement affectée au projet, y compris le personnel de conception et de développement de logiciels. » « Notre proposition prévoit un financement continu pour une équipe spécialisée, plutôt qu’un financement de projet limité dans le temps. »
   • Remarques : Il peut s’agir d’un changement par rapport à la pensée conventionnelle, qui considère les projets de TI comme des immobilisations comportant des investissements initiaux importants suivis d’une dépréciation progressive. Cette dépréciation, associée à des délais d’exécution pour effectuer les améliorations subséquentes, pose des problèmes majeurs (par exemple, lenteur à réagir aux erreurs critiques, incapacité de mettre en œuvre une nouvelle orientation stratégique, accroissement des anciens systèmes et ainsi de suite). Les points de vue proposés ici sont liés à la durabilité, soulignant la nécessité d’une attention continue (sous la forme d’une équipe spécialisée, dont la taille et la forme pourraient changer au fil du temps). Nous pouvons ainsi éviter des coûts de remplacement importants à plus long terme.
8. Existe-t-il des exigences préalables sur le fonctionnement du système? Dans l’affirmative, combien d’exigences sont incluses?
   • Causes de préoccupation : « Nous avons passé l’année dernière à examiner nos besoins opérationnels, et nous avons inscrit des centaines d’exigences dans la proposition de projet (ou la présentation au Conseil du Trésor, l’Énoncé de projet, etc.), pour nous assurer d’obtenir exactement ce dont nous avons besoin. »
   • Bon signe : « Nous nous concentrons davantage sur les résultats que nous souhaitons obtenir du nouveau système. Nous avons mis au point un arriéré des récits des utilisateurs (relier un besoin de l’utilisateur à une utilisation du système) pour guider le travail de l’équipe, plutôt que de produire une liste détaillée des exigences techniques. »

Permettre au personnel d’offrir de meilleurs services

9. A-t-on clairement déterminé un propriétaire d’entreprise unique et habilité qui est responsable du projet?
   • Causes de préoccupation : « La responsabilité du projet est partagée entre plusieurs cadres supérieurs (ou ministères). » « Le projet relève de plusieurs cadres (un comité). » « Ce cadre est le responsable opérationnel, et ce cadre (autre) est le responsable technique. »
   • Bon signe : Un cadre supérieur en particulier (doté de pouvoirs de dépenser et d’embaucher) doit rendre compte de l’atteinte des résultats prévus du projet. Ce cadre peut embaucher du personnel technique (p. ex. CS, IS, etc.) pour former des équipes multidisciplinaires.
10. De quelle façon les membres de l’équipe du projet se renseigneront-ils sur la conception du projet auprès du personnel de première ligne et opérationnel?
    • Causes de préoccupation : « Les membres de la direction des directions opérationnelles participent à la conception du projet. » « Nous avons envoyé un sondage au personnel de première ligne pour recueillir leurs commentaires. » « La modification des processus opérationnels est hors de la portée ce projet. »
    • Bon signe : « Nous effectuons des recherches sur la conception aux côtés du personnel de première ligne afin de comprendre leurs réalités opérationnelles. » « Nous sommes autorisés à modifier les processus opérationnels afin d’habiliter le personnel de première ligne et d’améliorer son expérience d’interaction avec le service. »
11. Combien de technologues (concepteurs, chercheurs sur la conception, développeurs de logiciels ou gestionnaires de produits) participent directement à la planification et à l’exécution du projet? (Remarque : Ce total devrait exclure les gestionnaires de projets, analystes d’entreprise et rôles traditionnels de supervision.)
    • Causes de préoccupation : « Aucune. » « Le projet a été entièrement planifié par nos unités opérationnelles, des politiques ou des programmes. »
    • Bon signe : « Nous avons à notre disposition une équipe multidisciplinaire comprenant des technologues qui sont habilités à définir l’orientation du projet et à suivre des cours corrects au besoin. »
12. La majeure partie des ressources affectées à ce projet sera-t-elle consacrée aux travaux de réalisation? Quelle proportion du financement sera utilisée pour la « surveillance » (gérer, générer de la documentation comme des rapports de projet, présenter des mises à jour, évaluer la conformité, etc.) plutôt que « l’exécution » (concevoir des interfaces, rédiger le code, effectuer des recherches auprès des utilisateurs, etc.)?
    • Causes de préoccupation : « Plus de 25 % de nos ressources sont affectées à la planification, à la conformité et à la surveillance des projets. »
    • Bon signe : « Notre équipe est habilitée à prendre des décisions directement, en fonction des commentaires des utilisateurs. » « Nous avons exclu nos comités habituels et nos procédures de surveillance traditionnelles du projet. »
    • Remarque : Un important contingent de personnel de planification, de conformité et de surveillance constitue une réponse naturelle au fardeau important que représente la production de rapports pour les équipes ministérielles. Une approche pour encourager « l’exécution » serait de réduire ce fardeau en demandant des « démonstrations, pas des notes de service ». Les équipes responsables des initiatives logicielles devraient faire une démonstration directe de ce logiciel, au lieu de rédiger de longs rapports sur leurs progrès. Si des rapports d’étape sont nécessaires (par exemple, en raison d’exigences juridiques ou stratégiques, ou pour créer une « trace documentaire »), ils doivent être brefs, accompagnés de liens ou d’instructions sur la façon d’accéder au logiciel.

Travailler ouvertement par défaut et utiliser des normes et des solutions ouvertes

13. Qui sera propriétaire d’un logiciel personnalisé développé dans le cadre de ce projet? Qui pourra modifier le logiciel?
    • Causes de préoccupation : « Le fournisseur. »
    • Bon signe : « Le gouvernement du Canada’ ou “il sera publié en vertu d’une licence à source ouverte approuvée. »
14. Ce projet utilisera-t-il un logiciel propriétaire? Comment éviterez-vous le verrouillage par le fournisseur?
    • Causes de préoccupation : « Nous utilisons des logiciels propriétaires des fournisseurs privilégiés de notre ministère. » « Nous utilisons une entente de société existante pour acquérir des logiciels pour ce projet. »
    • Bon signe : « Non. » « Oui, mais seulement là où il faut se relier aux systèmes existants. » “Oui, mais avec la possibilité d’exporter entièrement toutes les données contenues dans le logiciel propriétaire. »
15. Y aura-t-il des coûts de licence permanents de la part des fournisseurs pour les logiciels personnalisés ou propriétaires? Dans l’affirmative, combien de temps durera le contrat pour de telles licences?
    • Causes de préoccupation : « Le contrat de licence dure plus de trois ans. »
    • Bon signe : « Oui, mais les licences sont en tranches d’un an, sans verrouillage. Nous travaillons à remplacer le logiciel propriétaire et nous cesserons de le renouveler une fois que nous aurons mis en place une solution de source ouverte. »

Gérer les risques en matière de sécurité et de protection des renseignements personnels

16. À quelle fréquence votre ministère met-il habituellement à jour ses services existants? À quelle vitesse peut-il publier des correctifs sur des bogues logiciels ou des vulnérabilités de sécurité?
    • Causes de préoccupation : « 1 à 2 fois par trimestre. » « Seulement quand cela est nécessaire. »
    • Bon signe : « De 5 à 10 fois par mois (ou plus). » « Nous utilisons un pipeline d’intégration continue. » « Nous avons des systèmes de surveillance automatisés. »
    • Remarque : La fréquence des mises à jour est un bon indicateur de la capacité d’un ministère à réagir aux menaces de sécurité en mouvement rapide, à intégrer les résultats de la recherche aux utilisateurs finaux, et plus encore.

Intégrer l’accessibilité dès le départ

17. Comment allez-vous vous assurer que le logiciel que vous construisez ou achetez répond aux exigences gouvernementales en matière d’accessibilité?
    • Causes de préoccupation : « Nous améliorerons l’accessibilité une fois que nous aurons acheté le logiciel. » « Le logiciel répond déjà aux exigences d’accessibilité, nous n’avons donc plus besoin de faire de tests. » « Notre cas d’utilisation n’a pas besoin de répondre aux exigences d’accessibilité. »
    • Bon signe : « Nous avons l’intention de tester le logiciel avec les utilisateurs d’outils d’accessibilité (par exemple, par le biais du programme d’accessibilité, d’adaptation et de technologie informatique adaptée de Services partagés Canada). » « Nous avons une équipe spécialisée afin d’apporter des améliorations continues au logiciel, une fois celui-ci lancé. » « Nous avons inclus dans nos documents de demande de propositions la conformité aux Règles pour l’accessibilité des contenus Web2.1 AA comme une exigence obligatoire. » « Nous avons un énoncé sur l’accessibilité accessible au public qui décrit la façon dont nous répondons aux préoccupations en matière d’accessibilité et dont nous les abordons. »

Indicateurs d’exécution efficace

Certains comportements indiquent qu’un programme fournit un logiciel de manière fiable et efficace. D’une manière générale, vous devriez être en mesure d’effectuer régulièrement les activités suivantes :

• utiliser une démonstration;
• participer à une séance de tests de recherche et d’utilisabilité avec des personnes qui utilisent réellement le logiciel;
• constater les modifications apportées au code ouvertement (par exemple, sur GitHub, GitLab, etc.);
• joindre une session de planification ou de révision.

Si un programme vous permet de réaliser ces quatre activités de façon régulière, il est probable qu’il offre un logiciel fiable.

Des questions ? Veuillez contacter : lucas.cherkewski@tbs-sct.gc.ca ou cds-snc@tbs-sct.gc.ca