Approche d'ingénierie

Cette page décrit la manière dont le travail est organisé et ce qui en garantit la qualité. Elle ne remplace pas la proposition : elle répond à la question que posent généralement les ingénieurs du client — en quoi cela diffère-t-il d'une présentation.

Ce qu'est la plateforme

La plateforme, c'est ce qui ne connaît aucun service en particulier.

La définition n'est pas descriptive mais vérifiable. Le test s'applique à n'importe quelle ligne de code : s'il faut la modifier pour ajouter un nouveau service, ce code n'appartient pas à la plateforme.

PlateformeHors plateforme
Mécanisme de contrôle d'un champRègle « la date de naissance ne peut suivre la date d'enregistrement »
Mécanisme de demande interadministrativeDemande de l'acte de naissance
Moteur d'itinéraire avec suspension des délaisItinéraire d'un service donné
Moteur de gabarits avec code lisible par machineTexte du formulaire

Le service, lui, n'est pas un programme. Un service est un enregistrement de données : formulaire, règles, itinéraire, états, délais, demandes de données, créances, gabarits, notifications, niveau d'accès requis. La plateforme l'interprète. D'où ce qui justifie toute l'entreprise : publier un service n'est pas publier une version de la plateforme.

Ce n'est pas une hypothèse de projet

Le modèle reproduit l'architecture d'un système de services publics en exploitation, construit par des membres de notre équipe. Le service y est un ensemble de réglages de blocs, conservé sous forme de spécification lisible par machine dans un dépôt distinct, et non un programme inscrit dans le code de la plateforme.

Pour l'appréciation du risque, la différence est importante. Nous ne validons pas une hypothèse aux dépens du client : l'approche a été éprouvée à l'échelle nationale, et nous savons non seulement qu'elle fonctionne, mais aussi où elle achoppe. Tous les écueils connus figurent parmi les risques, assortis de mesures.

Pourquoi le service suivant coûte moins cher

Sur les quatorze éléments que requiert le premier service, aucun n'est codé pour le suivant. Restent la description, l'assemblage et, si l'administration est nouvelle, son raccordement.

coût relatif d'un service

  ██████████████████████████████████  premier service : étude, assemblage, poste de travail, formation
  ███████████████████  service d'une nouvelle administration
  ██████████  service exigeant un nouveau type de données
  ███  service de la même administration
  ────────────────────────────────────

La courbe décroît non parce que nous gagnons en expérience, mais parce que le raccordement d'une administration est un travail unique, que les services de cette même administration réutilisent intégralement. D'où la règle de planification : une vague se constitue par administration, et non par popularité des services. Cinq services d'une même administration coûtent environ quatre fois moins que cinq services relevant de cinq administrations.

Zéroélément du constructeur à coder pour le service suivant : il s'assemble par réglage
Fractions
de pour cent
du coût de la plateforme pour un service assemblé sur une plateforme déjà en place
Une
seule fois
le raccordement d'une administration : les services de cette administration le réutilisent intégralement

La troisième carte importe autant que les deux premières. Le raccordement d'une administration est un travail distinct, d'une ampleur comparable à celle de tous les services de cette administration réunis. Nous le disons d'emblée : le client qui l'apprendrait plus tard serait fondé à s'estimer induit en erreur.

Ce qui vérifie la conception

La conception forme une chaîne unique, et sa cohérence est vérifiée par un programme, non par relecture. Une rupture dans n'importe quel maillon arrête la vérification.

exigence → cas d'usage → composant → plan → chiffrage


chaque exigence possède un fondement et une condition de réception vérifiable
chaque exigence est couverte par au moins un cas d'usage, le lien étant réciproque
chaque exigence est rattachée à un composant — sans quoi personne ne la réalise
chaque exigence dispose d'un plan de travaux, avec dépendances et risque
la charge des plans concorde avec les fiches de composants
les fiches de composants concordent avec le modèle de calcul
123exigences, chacune avec fondement et réception
56cas d'usage avec leurs variantes
27composants, comportement en cas de panne analysé
123plans de réalisation

Le premier passage de la vérification a relevé huit ruptures. Elles ont été traitées sur le fond, et non par ajustement des chiffres : un cas d'usage d'essais avec procès-verbal a été créé pour les exigences non fonctionnelles, le plan de sortie et la conformité des licences ont été rattachés à la réception de la livraison, et un renvoi superflu a été supprimé. Le modèle de calcul n'en a pas été modifié — et il ne devait pas l'être : la vérification détecte les écarts, elle ne les réécrit pas.

La règle de propriété

Le code source, la documentation et les procédures de déploiement sont remis à chaque livraison, et non à l'issue du programme. La remise conditionne la clôture de la réception : si elle n'est pas confirmée, la livraison n'est pas reçue.

La vérification est simple et littérale : les agents du client déploient un environnement depuis zéro en suivant la documentation, sans notre intervention. Une plateforme que nous seuls savons déployer reste la nôtre, quelle que soit la forme juridique donnée aux droits.

Pour aller plus loin

La proposition dans son ensemble →

Les catalogues complets des exigences, des cas d'usage, de l'architecture et des plans de réalisation sont remis dans un dossier distinct, sur demande.