Comment fonctionne la sous-phase Bêta
Où cela s’inscrit
Les points de contrôle qu’un service numérique du GC doit franchir shows where Beta comes in the whole journey, checkpoint by checkpoint.
Bêta privée et bêta publique
Ce qui a changé depuis l’Alpha
Ce qui a bougé, c’est que le service est réel et que ce que les gens y font compte. La demande de quelqu’un existe ensuite.
Des gens essayaient aussi des choses en Alpha : leur arrivée n’est donc pas le changement. C’est pourquoi un prototype testé avec cinq vrais utilisateurs relève encore de l’Alpha, et pourquoi la plus petite version qui fonctionne de bout en bout appartient ici.
Les deux parties
Bêta privée. La Bêta commence en privé. Un nombre limité de personnes sont invitées à utiliser le vrai service, pour que l’équipe puisse recueillir des commentaires et l’améliorer pendant que l’auditoire est encore assez petit pour qu’on puisse s’excuser auprès de lui.
Bêta publique. Une fois le service amélioré et l’équipe convaincue qu’il peut être exploité à grande échelle, il s’ouvre à quiconque en a besoin. S’il remplace un service existant, il fonctionne à côté de l’ancienne façon jusqu’au lancement.
Ni l’une ni l’autre n’est un lancement
Ni la bêta privée ni la bêta publique n’est un lancement. Le lancement, c’est quand le service devient le service officiel pour les personnes qu’il sert. S’il existait une façon de faire antérieure, c’est le moment où elle est retirée, et cette façon antérieure est ce que les gens utilisaient réellement avant : un formulaire papier, une ligne téléphonique, une boîte de réception, ou une application qui fonctionne depuis quinze ans. Si le service est nouveau, il n’y a rien à retirer. Dans les deux cas, c’est le lancement qui met fin à la Bêta.
Si le service en remplace un existant, gardez l’ancien en fonction jusqu’à ce que le nouveau soit véritablement en service. La Bêta n’est pas le moment de l’éteindre. Si le service est nouveau, il n’y a rien à garder en fonction, et ceci ne s’applique pas.
Avant de commencer la Bêta
LE CONTRAT
Le contrat que vous signez survivra au service
Quand vous achetez, le contrat, peu importe le moment du parcours où il a été signé, est ce avec quoi le ministère devra vivre. La signature est le moment où le ministère a un vrai rapport de force, parce que rien n’est encore engagé.
Tout ce qui rend un service possible à quitter plus tard se gagne ou se perd à la signature :
- les droits de sortie et la portabilité des données, inscrits dès le départ
- le code dans un dépôt que le ministère contrôle, dès le premier jour
- la date de fin, et le délai réel pour renouveler ou remettre en concurrence
- les clauses d’accessibilité, et un rapport de conformité en matière d’accessibilité du fournisseur. Au Canada, la vérification de l’accessibilité se fait au moment de l’achat : un service acheté sans ces clauses est un service que vous paierez deux fois pour le corriger.
Un service qui n’a jamais été conçu pour être quitté coûte cher à quitter, et à ce moment-là le ministère n’a plus aucun rapport de force. L’approvisionnement couvre la façon d’acheter, et « À quoi ressemble un bon contrat » énonce les clauses.
Ce qu’il faut construire et prouver en Bêta
L’équipe qu’il vous faut
La Bêta est la partie la plus longue et la plus coûteuse de la Création. Attendez-vous à des mois, et attendez-vous à ce que le coût soit dominé par la construction ou la configuration.
Gardez l’équipe de l’Alpha. Les personnes qui ont fait la recherche et le prototypage portent l’empathie, le contexte et l’élan. Confier le service à une équipe neuve au moment où il devient réel jette les trois.
Les rôles minimaux pour soutenir la Bêta. Une personne peut en cumuler plusieurs.
- Responsable de produit décide de ce qui figure dans la première version réelle et de ce qui attend, et détient le pouvoir de dire non.
- Gestionnaire de la livraison garde la construction en mouvement et tient l’échéancier par rapport à la date de lancement.
- Développeurs ou équipe du fournisseur construisent ou configurent le vrai service.
- Concepteur fait passer le service d’une idée éprouvée à quelque chose que les gens peuvent réellement utiliser.
- Chercheur en expérience utilisateur mène la validation avec de vrais utilisateurs, et continue de trouver ce qui ne va pas.
- Exploitation mettent en place ce sur quoi le service fonctionne, et se préparent à l’exploiter.
- Autorité contractante signe le contrat, et est la seule personne qui peut tenir le fournisseur aux clauses de sortie.
- Responsable opérationnel de l’application accepte le risque qui subsiste, finance le travail, et donne le feu vert au lancement.
CAUTION
Quand la Bêta tourne mal
Quelques signes à surveiller :
Le prototype a été promu.
Le code jetable de l’Alpha est devenu le vrai service, et il porte tous les raccourcis pris à l’époque où il était censé être jeté.
Le contrat a été signé à la hâte.
Aucun droit de sortie, aucune portabilité des données, le code dans le dépôt du fournisseur. Le ministère loue désormais son propre service.
La validation a été omise.
Le service est passé du prototype à tout le monde : ses premiers vrais utilisateurs sont donc le public entier.
Personne n’est responsable du tableau de bord.
Le service est en fonction et aveugle, et la seule partie qui peut le voir est le fournisseur.
L’équipe qui l’a construit n’est pas celle qui l’exploitera,
et rien n’a été consigné.
Le lancement est devenu l’objectif.
C’est la date qu’on défend plutôt que le service, et on brade la qualité pour la respecter.
UN EXEMPLE RÉEL
Phoenix a sauté le projet pilote et a été lancé pour tout le monde d’un coup
En 2016, le gouvernement du Canada a remplacé son système de paye vieux de 40 ans par Phoenix. Pour tenir la date et le budget, le projet pilote prévu, un ministère en premier, a été abandonné, des fonctions de paye essentielles ont été retirées, et les essais du système ont été écourtés. Le ministère connaissait de graves faiblesses, et Phoenix a quand même été mis en service, pour tout le monde, en deux vagues.
En quelques mois, des dizaines de milliers de fonctionnaires ont été mal payés ou pas payés du tout : chèques erronés, chèques manquants, des gens vérifiant leurs propres talons à la calculatrice. L’arriéré a grimpé à des centaines de milliers de dossiers de paye, et corriger le système a coûté plusieurs fois ce que sa construction avait coûté. Le vérificateur général a parlé d’un échec incompréhensible de la gestion et de la surveillance de projet. Le groupe invité, le volume plafonné, la décision de continuer prise sur des preuves : ce que cette page demande à la Bêta est exactement ce que Phoenix a sauté.
Comment savoir que la Bêta est terminée
Les critères d’achèvement. La Bêta est terminée quand le service a traversé la bêta privée puis la bêta publique, a été utilisé par de vraies personnes à grande échelle, et a tenu. Il livre le parcours complet, de bout en bout. Le service respecte la norme d’accessibilité et ce que les tests ont révélé a été corrigé, l’évaluation de la protection de la vie privée est faite, le tableau de bord est en fonction, et le soutien est doté.
Le ministère peut le porter après le lancement
C’est le test pour lequel ce guide existe. Le ministère peut soutenir le service et continuer de l’améliorer, chaque année, jusqu’à ce qu’il soit remplacé ou mis hors service. S’il ne le peut pas, le service n’est pas prêt à être lancé, aussi belle que soit la démonstration.
Soutenir veut dire des personnes nommées ayant du temps dans leur semaine, de l’argent dans un budget qui se renouvelle, et un endroit où un utilisateur peut aller quand le service lui fait défaut. Un lancement sans rien de tout cela produit un service qui se dégrade dès son premier jour et dont personne n’a la responsabilité de s’apercevoir.
La décision de lancer se prend au regard des critères que vous avez déjà rédigés
Les critères de feu vert et de feu rouge ont été convenus au début de la Bêta, avant qu’une date de lancement existe. La décision à la fin de la Bêta consiste à lire les preuves au regard de ces critères, et rien de plus. Réécrire les critères une fois la date inscrite à l’agenda d’un ministre annule l’intérêt de les avoir rédigés.
En avant vers la Stabilisation,
quand le service est lancé et devient le service officiel pour les personnes qu’il sert. Le travail passe de le construire à le stabiliser.
quand la validation avec de vrais utilisateurs montre que l’approche ne fonctionne pas, et qu’il faut la repenser avant d’y mettre plus d’argent.
Stop,
quand les preuves disent que le service ne devrait pas être lancé du tout. C’est rare et c’est coûteux, et c’est quand même moins cher que de lancer quelque chose qui ne fonctionne pas.
Liste de sortie. La liste de l’Alpha portait sur la construction, et tout ce qui s’y trouvait était quelque chose qu’on pouvait demander à un fournisseur de livrer. Celle-ci porte sur le ministère : des personnes ayant le service dans leurs objectifs, un budget qui se renouvelle sans que quiconque ait à plaider de nouveau, et des autorisations qui appartiennent à un titulaire nommé. Aucun fournisseur ne peut prendre ces engagements pour vous, et chacun doit être vrai le jour où le service cesse d’être un projet pour devenir la responsabilité à long terme de quelqu’un. Avant de passer à la Stabilisation, ayez ceci prêt :
Lancement
La Bêta se termine ici. Le service devient le service officiel, de vraies personnes en dépendent, et le ministère en répond à partir de ce moment jusqu’à son remplacement ou son retrait.
Les instruments officiels dans Bêta
Tout ce qui est officiel et à quoi il arrive quelque chose pendant Bêta, et ce que ce quelque chose est. L’étiquette dit à quelle étape l’instrument parvient ici, non qu’il soit terminé.
Placer un instrument dans une sous-phase est un choix éditorial propre à ce guide, ancré autant que possible sur une véritable échéance inscrite dans l’instrument lui-même. Le détail complet, y compris qui fait le travail et ce que le responsable opérationnel fait personnellement, se trouve dans le tableau complet des instruments.
- Vérifier
- Déterminer si cela s’applique au service.
- Rassembler
- Transmettre le jugement opérationnel que seule l’équipe du service détient. Quelqu’un d’autre le met par écrit.
- Remplir
- La chose est réellement produite.
- Signer ou accepter
- Une personne désignée y appose son nom, ou reçoit le résultat de quelqu’un d’autre et décide quoi en faire.
- Soumettre
- Transmis, déposé, inscrit ou publié là où la règle l’exige.
Ce que signifient les étiquettes
Every service
L’exercice qui énumère ce qui pourrait mal tourner, classe chaque élément selon sa probabilité et l’ampleur du dommage, et énonce le risque qui subsiste une fois les mesures de protection en place.
Deuxième passage, contre le système réellement construit. Ses résultats entrent dans l’évaluation du risque résiduel sur laquelle repose l’autorisation.
- Évaluation et autorisation de sécurité, se terminant par l’autorisation d’exploiter (EAS, AE)AutorisationSigner ou acceptersource
L’autorisation officielle permettant au service de fonctionner en production.
L’autorité approbatrice approuve la conception détaillée, approuve l’installation en production dans les projets plus grands, puis signe l’autorisation d’exploiter avant le début de l’exploitation. Elle n’expire pas et ne se renouvelle pas selon un calendrier.
- Analyse des répercussions sur les activités (ARA)ÉvaluationRassembler
L’exercice qui détermine la criticité du service, et qui produit quatre chiffres : la durée maximale d’interruption admissible, le niveau de service minimal, l’objectif de temps de reprise et l’objectif de point de reprise.
Transmettre la liste des dépendances : les systèmes, fournisseurs, employés, installations et services partenaires dont celui-ci dépend, y compris là où l’on compte sur une autre organisation.
- Conformité en matière d’accessibilité et déclaration d’accessibilitéObligation permanenteRemplirSoumettresource
La conformité du service lui-même à la norme canadienne d’accessibilité pour les technologies de l’information et des communications, plus une déclaration publiée qui nomme ce qui n’est pas conforme, quelles sont les solutions de rechange, et quand les écarts seront comblés.
Testé au regard de la norme, constats corrigés, et déclaration publiée au plus tard le jour où l’obligation s’applique pour la première fois.
Le consentement écrit de Bibliothèque et Archives Canada sans lequel aucun document gouvernemental ne peut être détruit.
Le calendrier de conservation et de disposition est fixé. Toute lacune est signalée avant le lancement plutôt que découverte au moment du retrait.
Un ensemble de choses que tout système détenant de l’information gouvernementale doit pouvoir faire : appliquer les règles de conservation et de disposition d’une façon vérifiable, porter des métadonnées, prendre en charge les structures de classification du ministère, fonctionner avec d’autres systèmes, et exporter en bloc dans des formats ouverts.
Confirmez que le système construit ou acheté fait réellement ces choses. L’exportation en bloc est celle qui manque le plus souvent et la plus coûteuse à découvrir tard.
Les dispositions de rétablissement propres à l’équipe du service : comment ce système se relève, dans quel ordre ses composants sont restaurés, et la preuve par les essais que la restauration fonctionne.
Les sauvegardes, la procédure de restauration et les priorités de restauration existent et ont été mises à l’essai au moins une fois avant le lancement, plutôt que d’être présumées.
L’obligation de disposer d’un moyen de repérer, de contenir et de signaler un incident de cybersécurité avant qu’il survienne, et de le signaler dans la chaîne pangouvernementale quand il survient.
Savoir avant le lancement qui appeler à 2 h du matin, comment le service est surveillé, et quelle est la voie d’escalade. Positionnement éditorial : l’obligation est permanente plutôt que liée au lancement.
- Service dans les deux langues officiellesObligation permanenteRemplirSoumettre
L’obligation d’offrir et de fournir le service en français et en anglais en même temps et selon la même norme.
Les deux langues sont lancées ensemble. Lorsqu’une présentation au Conseil du Trésor est en cause, l’annexe sur les langues officielles l’accompagne.
- Décision d’hébergement de l’application, et le nuage public par défautExamenSigner ou acceptersource
La décision sur l’endroit où le service fonctionne, prise au regard d’un ordre de préférence pangouvernemental : logiciel-service avant plateforme avant infrastructure, et nuage public avant hybride avant privé avant hors nuage.
L’entente d’hébergement est en place et la décision est consignée.
- Préparation à l’accès à l’information, et l’obligation de documenterObligation permanenteRemplir
Tout ce que le service consigne peut être demandé par une demande d’accès, et les décisions ayant une valeur opérationnelle doivent d’abord être documentées.
Les documents sont structurés et repérables, non éparpillés dans des systèmes que personne ne peut fouiller.
Only if it applies
- Évaluation de la sécurité matérielle et autorisation d’occuper des locauxAutorisationRemplirSigner ou accepter
La deuxième filière de sécurité, menée en parallèle et couvrant les bâtiments, l’équipement et l’espace physique.
Lorsqu’un logiciel commandera de l’équipement de bâtiment, l’évaluation et l’autorisation doivent être terminées avant la mise en œuvre, et la source recommande de commencer tôt.
Applies when Seulement si le service touche l’espace physique : nouveaux locaux, matériel entre les mains des gens, bornes, ou logiciel qui commande des portes, des barrières, l’éclairage ou le chauffage. Un service hébergé dans le nuage sans matériel y échappe habituellement.
- Plan de continuité des activités (PCA)PlanRassembler
Les dispositions écrites pour qu’un service essentiel continue d’être offert à un niveau minimal acceptable pendant une perturbation, et pour le rétablir ensuite.
Avant le lancement, les étapes de rétablissement et les solutions de contournement du service vont au coordonnateur pour que le plan le couvre dès le premier jour. Positionnement éditorial : la directive ne fixe aucun point de contrôle au lancement.
Applies when Seulement si l’analyse des répercussions sur les activités marque le service comme essentiel, c’est-à-dire qu’une perturbation causerait un préjudice élevé ou très élevé. Un ministère interprète cela comme devant se rétablir aux niveaux de service minimaux en 72 heures.
- Liste de vérification et évaluation des facteurs relatifs à la vie privée (ÉFVP)ÉvaluationRemplirSoumettresource
Un examen structuré des renseignements personnels que le service recueille, du droit de les recueillir, de leur circulation, de leur durée de conservation, et de ce qui pourrait arriver aux personnes en cas de problème.
Approuvée et déposée avant que de vrais renseignements personnels soient recueillis.
Applies when Les déclencheurs sont larges. Un programme nouveau ou substantiellement modifié qui crée, recueille, utilise, communique, conserve ou élimine des renseignements personnels entre dans la portée. De même pour leur utilisation à une fin administrative, l’impartition ou le transfert du programme, l’arrivée d’un tiers, un changement de la technologie qui les traite, ou l’automatisation d’une décision. Aucun seuil monétaire ni nombre d’utilisateurs.
Un questionnaire coté sur l’ampleur de l’incidence qu’une décision automatisée pourrait avoir sur les droits, la santé ou les intérêts économiques d’une personne, ou sur la durabilité continue d’un écosystème.
Remplie, approuvée et publiée avant la production. À partir du niveau d’incidence deux, un examen par les pairs est aussi exigé, et ses constats publiés avant le lancement.
Applies when Seulement si le service prend ou soutient une décision automatisée concernant une personne : cotation, classement, recommandation ou approbation automatique. Une fonctionnalité d’efficience ajoutée plus tard peut la déclencher sans que personne s’en aperçoive.
La déclaration écrite d’un fournisseur indiquant dans quelle mesure son produit respecte la norme d’accessibilité, clause par clause, avec les écarts nommés.
Fourni à l’adjudication du contrat et vérifié, non pris pour acquis. Une feuille de route de correction couvre ce qui n’est pas respecté.
Applies when Seulement à l’achat. Une construction interne n’a ni fournisseur ni rapport; l’obligation équivalente est l’évaluation de conformité du ministère lui-même au regard de la norme.
- Rapport d’atteinte substantielle à la vie privéeDéclarationVérifier
Le rapport qu’un ministère doit produire lorsque des renseignements personnels sont perdus, consultés ou communiqués d’une façon dont on pourrait raisonnablement s’attendre à ce qu’elle cause un préjudice grave.
Savoir, avant le lancement, qui au ministère tranche le caractère substantiel et à quelle vitesse cette personne doit être informée par l’équipe.
Applies when Seulement lorsqu’une atteinte visant des renseignements personnels est jugée substantielle, d’après la sensibilité de l’information, le nombre de personnes touchées, et le caractère systémique ou non du problème. Un incident de cybersécurité touchant des renseignements personnels peut déclencher à la fois celui-ci et la voie de signalement en cybersécurité.
- Les langues officielles dans ce que vous achetezObligation permanenteSigner ou accepter
L’obligation d’inscrire les exigences relatives aux langues officielles au contrat, pour que le fournisseur soit contractuellement tenu de livrer les deux langues.
Les clauses figurent au contrat signé et les livrables sont vérifiés à leur égard.
Applies when Chaque fois qu’un fournisseur livre, héberge ou soutient une partie d’un service destiné au public, ou produit du contenu au nom du ministère. Les orientations sont établies par un avis sur la politique des marchés.
- Liste de vérification des exigences relatives à la sécurité (LVERS, formulaire TBS/SCT 350-103)PrésentationSigner ou accepterSoumettresource
Un court formulaire qui énonce, pour un contrat donné, exactement quelle sécurité le fournisseur et son personnel exigent : quel niveau d’information ils toucheront, quel filtrage chaque rôle exige, et si l’entreprise peut détenir de l’information gouvernementale dans ses propres bureaux.
L’autorité de projet signe son bloc; l’agent de sécurité signe le sien. L’attestation est confirmée avant l’adjudication, et le filtrage du fournisseur peut prendre des mois : un départ tardif retarde donc le contrat, non la paperasse.
Applies when Seulement lorsque le fournisseur ou son personnel aura accès à de l’information ou à des biens Protégés ou Classifiés, entrera dans des sites d’accès restreint, ou se connectera électroniquement aux systèmes du ministère, ce qui comprend tout accès aux renseignements personnels que le ministère détient. En l’absence d’exigences de sécurité, aucune liste de vérification n’est produite et le ministère l’atteste à la place.
- Filtrage de sécurité de l’organisation et du personnel du fournisseurAutorisationRassemblerSigner ou acceptersource
Les attestations qu’une entreprise et ses employés doivent détenir avant de toucher à du travail gouvernemental sensible.
Confirmé avant l’adjudication. Le filtrage individuel peut prendre des mois, et le nouveau personnel qui se joint en cours de contrat en a besoin aussi.
Applies when Chaque approvisionnement dont la Liste de vérification des exigences relatives à la sécurité recense une exigence de sécurité, et il en va de même pour les sous-traitants à tous les niveaux. Le filtrage de l’organisation couvre Protégé A, B et C; une attestation d’installation vise le Classifié.
- Profil de sécurité infonuagique, garde-fous, et autorisation infonuagiqueAutorisationRemplirSigner ou acceptersource
Le travail de sécurité supplémentaire que porte un service hébergé dans le nuage : un profil de contrôles prêt à l’emploi sur lequel construire, des garde-fous qui doivent être mis en place, validés et déclarés dans les 30 premiers jours ouvrables suivant l’obtention d’un compte infonuagique, et une évaluation de sécurité qui tient compte du partage entre ce que fait le fournisseur et ce que fait le ministère.
Garde-fous en place dans le nouvel environnement, évaluation de sécurité faite au regard du partage des responsabilités, et autorisation signée avant le début de l’exploitation.
Applies when Seulement pour les services hébergés dans le nuage. Le profil de contrôles Protégé B est le point de départ habituel. Le Centre pour la cybersécurité évalue séparément les fournisseurs de services infonuagiques : un ministère hérite donc de cette évaluation plutôt que de la refaire, et n’évalue que sa propre configuration et son propre usage.
- Services de justificatifs et d’ouverture de session du gouvernement du CanadaObligation permanenteRemplirSoumettre
Les services d’ouverture de session communs qu’un ministère peut utiliser plutôt que de construire les siens : le service de justificatifs à marque gouvernementale, l’option commerciale fondée sur les banques, et la plateforme d’ouverture de session fédérée plus récente.
L’intégration, l’attestation et les essais dans l’environnement d’acceptation prennent du temps réel au calendrier et constituent un retard de lancement courant.
Applies when Tout service destiné au public où les clients ouvrent une session. L’adhésion à une plateforme commune suppose des vérifications de conformité et des essais avant la mise en service, et c’est l’équipe de la plateforme qui les établit.
Les règles pour tout ce que le public voit : le domaine, l’en-tête et le pied de page globaux, la signature et le mot-symbole du gouvernement du Canada, les gabarits de page obligatoires, l’architecture de l’information, et le guide de style du contenu.
L’adresse Web est réglée et l’outil officiel d’analytique Web est en place. Amorcez cela avec l’équipe Web du ministère avant de promettre une date de lancement aux intervenants.
Applies when Chaque site Web et chaque application Web destinés au public. À l’intérieur du ministère, le chef des communications répond des sites Web destinés au public et des applications mobiles, et la directive les assujettit tous deux à son annexe D, la Norme sur les sites Web et les applications mobiles destinés au public. La même directive exige l’outil officiel d’analytique Web administré par Service Canada.
- Web adaptatif, ou application mobile nativeObligation permanenteRemplir
La règle voulant qu’un service destiné au public fonctionne correctement sur un téléphone, et que le choix d’une application téléchargeable plutôt que d’une page Web adaptative soit justifié.
Testé sur de vrais appareils avant le lancement. Une application native passe en plus par le processus de publication central.
Applies when Chaque site Web et chaque application Web destinés au public.
- Publication proactiveDéclarationSoumettre
Une publication qui se fait sans que personne le demande, en vertu d’une obligation légale.
Le contrat qui achète la construction est publié une fois adjugé.
Applies when Déclenchée par ce que fait le service plutôt que par sa taille. Tout contrat de plus de 10 000 $ déclenche la publication des contrats; un programme de subventions ou de contributions déclenche l’autre.
Les hypothèses de cette page
Vous travaillez déjà selon les Normes relatives au numérique du gouvernement du Canada : concevoir avec les utilisateurs, itérer et améliorer fréquemment, travailler ouvertement, utiliser des normes et des solutions ouvertes, gérer les risques en matière de sécurité et de protection des renseignements personnels, intégrer l’accessibilité dès le début, permettre au personnel d’offrir de meilleurs services, être de bons gestionnaires de données, concevoir des services éthiques et collaborer largement, ainsi que selon la loi en matière de protection des renseignements personnels, de sécurité, de langues officielles et d’accessibilité. Les normes précisent comment le gouvernement travaille dans le monde numérique. Les six compétences numériques du gouvernement du Canada précisent ce que chaque fonctionnaire doit être capable de faire pour travailler ainsi, et la page sur l’équipe les présente. Le présent guide s’appuie sur elles.