Construire des services numériques publics : leçons du terrain

Construire des logiciels pour le secteur public ne ressemble à aucun autre domaine. Les enjeux sont plus élevés, les contraintes plus strictes, et les utilisateurs sont tout le monde — pas un segment choisi d’adopteurs précoces.

Après plus de 18 ans passés chez HMCTS, le ministère de la Justice, le ministère des Transports et le DWP, j’ai rassemblé un ensemble de principes qui distinguent les projets qui aboutissent de ceux qui s’enlisent.

1. Commencer par l’utilisateur, pas par le service

Le premier principe de conception de GOV.UK — « Partir des besoins » — semble évident. Il l’est rarement en pratique. Sur presque chaque mission, le brief initial décrit un système plutôt qu’un problème utilisateur.

Quand nous avons démarré le Possession Claims Service pour HMCTS, l’instinct était de reproduire le processus papier numériquement. Nous avons plutôt passé le premier sprint à cartographier qui utilisait réellement le service : des avocats déposant en masse, des justiciables non représentés déposant une seule fois, des juges examinant les preuves. Trois modèles mentaux complètement différents, un seul service.

// Cartographier les parcours utilisateurs avant d'écrire une ligne de code
interface UserJourney {
  persona:    'solicitor' | 'litigant-in-person' | 'judge';
  entryPoint: string;
  primaryTask: string;
  painPoints:  string[];
}

const journeys: UserJourney[] = [
  {
    persona:     'solicitor',
    entryPoint:  'bulk upload CSV',
    primaryTask: 'file 50+ claims per week efficiently',
    painPoints:  ['repetitive data entry', 'no batch status updates'],
  },
  {
    persona:     'litigant-in-person',
    entryPoint:  'GOV.UK search',
    primaryTask: 'understand what I need to do',
    painPoints:  ['legal jargon', 'no guidance on documents needed'],
  },
];

Le service qui en a résulté comportait trois parcours distincts. Chaque décision de contenu, chaque champ de formulaire, chaque message d’erreur a été rédigé pour un persona précis.

2. Traiter l’accessibilité comme de l’architecture, pas comme un audit

La plupart des équipes ajoutent l’accessibilité à la fin. Un rapide scan axe, quelques corrections de couleur, et on livre. Cela ne fonctionne pas — et dans le secteur public, ce n’est pas optionnel. La conformité WCAG 2.2 AA est une obligation légale au titre des Public Sector Bodies Accessibility Regulations.

Les équipes qui réussissent l’intègrent dans leur définition de « terminé » :

• Chaque nouveau composant a été testé avec un lecteur d’écran (NVDA + Chrome, VoiceOver + Safari)
• La navigation au clavier est vérifiée avant l’approbation de la pull request
• Le contraste des couleurs est vérifié dès la phase de conception, pas au développement

// Jetons de design garantissant des ratios de contraste
// — vérifiés selon WCAG 1.4.3 (ratio de contraste ≥ 4,5:1 pour le texte normal)
$gov-text-on-white:  #0b0c0c; // 21:1 — toujours sûr
$gov-link:           #1d70b8; // 4,54:1 sur blanc — passe de justesse
$gov-link-visited:   #4c2c92; // 5,0:1 sur blanc — passe
$gov-focus:          #ffdd00; // Anneau de focus très visible

3. Le CI/CD n’est pas optionnel sur les projets publics

Les services publics ont certaines des exigences de gestion du changement les plus strictes qui soient. Paradoxalement, c’est une raison d’investir massivement dans l’automatisation — non pas pour aller vite, mais pour prouver que chaque changement est sûr.

Sur notre mission pour le DfT, nous avons construit un pipeline qui imposait :

# Pipeline CI simplifié pour un service de style GDS
stages:
  - lint
  - unit-test
  - integration-test
  - accessibility-audit
  - security-scan
  - deploy-to-staging
  - smoke-test
  - deploy-to-prod

accessibility-audit:
  script:
    - npx axe-cli https://staging.service.gov.uk --tags wcag2a,wcag2aa
  allow_failure: false  # Verrou strict — les échecs d'accessibilité bloquent la mise en production

L’audit d’accessibilité était un verrou strict. Un scan axe en échec bloquait la mise en production. Aucune exception, aucun contournement sans acceptation de risque documentée par le product owner.

4. Le motif « figuier étrangleur » pour la modernisation du legacy

Chaque ministère possède quelque part un système mainframe vieux de 20 ans. Le motif du figuier étrangleur — router progressivement le trafic vers un nouveau service tout en maintenant le système legacy en vie — est la façon la plus sûre de moderniser sans une réécriture big-bang qui mettrait en péril des services publics.

La clé est de construire tôt une couche de routage :

// Middleware de routage « figuier étrangleur » simplifié
import type { Request, Response, NextFunction } from 'express';

const featureFlags = {
  useNewClaimsService: process.env.NEW_CLAIMS_ENABLED === 'true',
  useNewPaymentsFlow:  process.env.NEW_PAYMENTS_ENABLED === 'true',
};

export function routerMiddleware(req: Request, res: Response, next: NextFunction) {
  if (req.path.startsWith('/claims') && featureFlags.useNewClaimsService) {
    return next(); // Le nouveau service le prend en charge
  }
  // Repli vers le proxy legacy
  res.redirect(307, `${process.env.LEGACY_BASE_URL}${req.path}`);
}

Points clés à retenir

• La recherche utilisateur n’est pas une phase — c’est une activité continue tissée tout au long de la livraison
• L’accessibilité, c’est de l’architecture — concevez pour elle, testez-la, verrouillez dessus
• Automatisez tout ce qui est auditable — si une machine peut le vérifier, elle devrait le faire
• Étranglez le legacy — ne réécrivez pas, redirigez

La livraison numérique publique est difficile. Mais quand elle fonctionne, l’impact est immense — des millions de personnes utilisant des services qui les servent réellement. Cela mérite d’être bien fait.