L'étude de sol vient avant les plans

Sur Le Chantier, le fil rouge de cette série, le maître d'ouvrage arrive avec un programme précis : un immeuble de bureaux, quatre cents postes de travail, un amphithéâtre au rez-de-chaussée, deux niveaux de parking. Il sait exactement ce qu'il veut pouvoir faire dans son bâtiment.

Personne ne dessine pour autant. Avant le premier trait, un géotechnicien sonde le terrain. Nature du sol, profondeur du bon sol, présence d'une nappe, charges admissibles, zone sismique.

L'étude retarde le projet de quelques semaines. Elle décide pourtant du type de fondations, de la hauteur atteignable, du mode constructif et d'une bonne part du budget.

Le programme dit ce que le bâtiment doit permettre de faire. L'étude de sol dit ce à quoi il doit faire face. Deux questions différentes, deux moments différents, et l'ordre n'est pas négociable.

En logiciel, l'équivalent de l'étude de sol s'appelle les exigences non-fonctionnelles. C'est l'étape que personne ne réclame, que personne ne finance volontiers, et qui décide de l'architecture entière.

Six étapes, donc, et le plus clair de ce billet sur la deuxième, parce que c'est celle qu'on saute.

Les six étapes, vue d'ensemble

Le travail d'un architecte suit une séquence stable, quel que soit le projet. Chaque étape répond à une question, produit quelque chose, et rend la suivante possible.

flowchart TD A["1. Exigences fonctionnelles
ce que le système doit faire"] --> B["2. Exigences non-fonctionnelles
ce à quoi il doit faire face"] B --> C["3. Cartographie des composants"] C --> D["4. Choix de la stack technique"] D --> E["5. Conception et document
d'architecture"] E --> F["6. Support aux équipes
pendant la réalisation"] F -.->|"chiffre corrigé, exigence oubliée"| B classDef amont fill:#ede9e1,stroke:#8a4d16,stroke-width:1px,color:#3a3a3a; classDef pivot fill:#f5f2ec,stroke:#a0413e,stroke-width:2px,color:#1a1a1a; classDef aval fill:#f5f2ec,stroke:#b5651d,stroke-width:2px,color:#1a1a1a; class A amont; class B pivot; class C,D,E,F aval;
# Étape La question à laquelle elle répond Ce qu'elle produit
1 Exigences fonctionnelles Que doit faire le système ? Une liste de cas d'usage
2 Exigences non-fonctionnelles À quoi doit-il faire face ? Des chiffres : latence, charge, volumétrie, SLA
3 Cartographie des composants De quelles briques a-t-on besoin ? Un découpage et des responsabilités
4 Choix de la stack technique Avec quoi les construit-on ? Langages, frameworks, magasin de données
5 Conception et document Comment tout cela tient-il ensemble ? Le document d'architecture
6 Support aux équipes Le plan survit-il au réel ? Des arbitrages, des corrections, un document tenu à jour

Certains découpages comptent la rédaction du document comme une étape distincte de la conception. Je les garde ensemble : une conception qui n'est pas écrite n'existe pas vraiment, elle vit dans une seule tête et disparaît avec elle. Le document d'architecture a d'ailleurs son propre billet en fin de série.

Le processus est séquentiel sur le papier seulement. Un chiffre corrigé au sixième mois renvoie à l'étape 2, et tout ce qui suit bouge. C'est précisément pour ça qu'on essaie d'avoir les bons chiffres au premier mois.

Les étapes 3, 4 et 5 occupent les paliers suivants de la série. Ici, on reste sur les deux premières.

Fonctionnel et non-fonctionnel : deux questions distinctes

Sur Le Chantier, personne ne confond le programme et l'étude de sol. L'un est écrit par le maître d'ouvrage, l'autre est mesuré par un bureau spécialisé. Les deux documents n'ont ni le même auteur, ni le même vocabulaire, ni le même moment.

En informatique, la frontière est beaucoup plus floue, et c'est là que les projets dérapent. Le client arrive avec un cahier des charges fonctionnel de quatre-vingts pages et pas une ligne sur la charge attendue.

Exigence fonctionnelle Exigence non-fonctionnelle
Question Que doit faire le système ? À quoi doit-il faire face ?
Sur Le Chantier Un amphithéâtre de 200 places Un plancher qui tient 500 kg au mètre carré
Exemple logiciel L'utilisateur peut annuler sa commande L'annulation répond en moins de 400 ms pour 95 % des appels
Qui l'exprime Le métier, spontanément Presque personne, il faut aller la chercher
Quand on la découvre Au premier atelier En production, un jour de pic
Coût d'un oubli Une fonction à ajouter Une architecture à refaire

La dernière ligne est celle qui compte. Une fonction oubliée se rattrape : on l'ajoute au sprint suivant. Une exigence de charge oubliée ne se rattrape pas de la même façon, parce qu'elle ne se traduit pas par du code en plus, mais par des choix structurels qui sont déjà coulés.

Une exigence fonctionnelle décrit un comportement. Une exigence non-fonctionnelle décrit une contrainte que ce comportement doit respecter, à l'échelle et dans les conditions réelles d'exploitation.

Le vocabulaire varie selon les référentiels, et la définition des exigences non-fonctionnelles recouvre un périmètre large. Retiens la traduction opérationnelle : ce sont les exigences qui se chiffrent. Elles se transforment ensuite en capacités techniques, les qualités de service que couvre le billet suivant sur les *-ilities.

Les cinq grandeurs à chiffrer

Sur Le Chantier, l'étude de sol ne rend pas un avis littéraire. Elle rend des nombres : une contrainte admissible en kilopascals, une profondeur en mètres, un niveau de nappe. Un chiffre se vérifie, une appréciation se discute indéfiniment.

Cinq grandeurs suffisent à couvrir l'essentiel d'un système d'information classique.

Performance
Combien de temps

La latence d'une opération et le débit soutenu. Deux chiffres, jamais un seul.

Charge
Combien à la fois

Le régime courant, le pic, et la durée du pic. Le dimensionnement se fait sur le pic.

Volumétrie
Combien ça s'accumule

Taille unitaire, cadence, durée de rétention. La donnée reste après le trafic.

Concurrence
Combien en même temps

Le nombre de comptes ouverts ne dimensionne rien. Seuls les présents au même instant comptent.

SLA
Combien d'indisponibilité

Un taux, une plage de mesure, une définition de la panne. Sinon, ce n'est qu'un vœu.

Performance : la latence et le débit ne sont pas la même chose

Prends l'ascenseur de l'immeuble. La latence, c'est le temps entre le moment où j'appuie sur le bouton et le moment où je pose le pied au huitième étage. Le débit, c'est le nombre de personnes que la batterie d'ascenseurs transporte par heure.

Un ascenseur unique et très rapide affiche une excellente latence à quinze heures, et un débit catastrophique à neuf heures. Six ascenseurs lents font l'inverse.

En logiciel, la confusion produit exactement le même contresens. Ajouter dix instances derrière un répartiteur de charge augmente le débit sans retirer une milliseconde au temps de réponse d'une requête isolée. Poser le bon index sur une table améliore les deux à la fois.

Autre piège : la moyenne ment. Si 95 % des requêtes répondent en 100 ms et 5 % en huit secondes, la moyenne reste flatteuse pendant que 5 % des clients ferment l'onglet. Demande un percentile plutôt qu'une moyenne. « Moins de 400 ms pour 95 % des affichages » se mesure, « rapide » se discute.

Charge : le régime courant, le pic, et la durée du pic

Le hall d'entrée ne se dimensionne pas sur la fréquentation d'un mardi à quinze heures. Il se dimensionne sur neuf heures deux, quand quatre cents personnes veulent franchir les tourniquets en vingt minutes.

Le même raisonnement vaut pour un système : la moyenne annuelle de requêtes par seconde n'a jamais fait tomber personne, le pic si. Il faut donc trois nombres et pas un.

La saisonnalité est presque toujours métier, jamais technique. Fin de mois pour la paie, décembre pour le commerce, rentrée pour l'éducation, lundi matin pour à peu près tout le reste. Ces motifs se demandent au métier, qui les connaît parfaitement.

La durée du pic change la réponse d'architecture. Un pic de cinq minutes se tient avec du cache et une file d'attente. Un pic de trois heures tous les lundis se tient avec de la capacité réellement provisionnée.

Volumétrie : ce qui s'accumule ne disparaît pas

Les archives d'un bâtiment posent deux problèmes que le programme ignore : combien de mètres linéaires au bout de dix ans, et quelle charge au mètre carré sur le plancher du sous-sol. Un local d'archives sous-dimensionné ne s'agrandit pas après coup.

Côté logiciel, la volumétrie se calcule au lieu de s'estimer au doigt mouillé.

50 000 événements/jour x 2 Ko           ≈ 100 Mo/jour
100 Mo x 365 jours                      ≈ 36,5 Go/an
36,5 Go x 5 ans de rétention            ≈ 182,5 Go de données utiles
+ index, réplicas et sauvegardes        ≈ 400 à 550 Go à provisionner

Le calcul tient en quatre lignes et se fait avant le premier commit. Il décide du type de magasin de données, de la façon d'écrire les requêtes, de la stratégie d'archivage et du coût de la sauvegarde.

Un dernier point souvent raté : le chiffre du jour un ne sert à rien. C'est celui de l'année trois qui dimensionne, avec la croissance annoncée par le métier.

Utilisateurs concurrents : la jauge, pas l'annuaire

Quatre cents personnes travaillent dans l'immeuble, et elles franchissent toutes les tourniquets entre neuf heures et neuf heures vingt. Combien se tiennent dans le hall au même instant ? Quatre-vingt-dix, peut-être. C'est ce nombre-là qui donne la surface d'attente et le nombre de sas, pas les quatre cents noms de l'annuaire.

En informatique, trois nombres différents portent le même nom dans la bouche du client : les comptes ouverts, les utilisateurs actifs par jour, et les utilisateurs simultanés au pic. Seul le troisième dimensionne les pools de connexions, la mémoire, les sessions et parfois les licences.

Ne fabrique pas de ratio entre les trois. Si un système existe déjà, la donnée est dans les journaux d'accès. S'il n'existe pas, fais poser la question à celui qui connaît le métier, et écris l'hypothèse retenue en toutes lettres.

SLA : un contrat, pas un vœu

Le contrat de maintenance de l'ascenseur ne dit pas « il ne doit jamais tomber en panne ». Il dit un taux de disponibilité, un délai d'intervention, et ce qui se passe si l'engagement n'est pas tenu.

Un SLA logiciel a besoin des mêmes éléments : un pourcentage, une plage de mesure (24/7 ou heures ouvrées), une définition de ce qui compte comme indisponible, et le sort réservé aux fenêtres de maintenance annoncées.

Les mêmes cinq grandeurs, sous forme d'entretien : ce qu'on entend d'ordinaire, et ce qu'on cherche à obtenir.

Grandeur La question à poser La mauvaise réponse typique La bonne réponse
Latence En combien de temps l'écran s'affiche, pour quelle part des appels ? « Il faut que ce soit fluide » « Moins de 400 ms pour 95 % des affichages de la fiche client »
Débit Combien d'opérations par seconde en courant, combien au pic ? « Beaucoup, surtout le matin » « 40 commandes/s en moyenne, 300/s pendant deux heures les jours de soldes »
Volumétrie Combien d'enregistrements par jour, de quelle taille, gardés combien de temps ? « On garde tout » « 50 000 événements/jour, 2 Ko pièce, rétention légale de 5 ans »
Concurrence Combien d'utilisateurs actifs en même temps au pic ? « On a 12 000 clients » « 12 000 comptes, 1 500 actifs par jour, 300 simultanés à 9 h »
SLA Quel taux, sur quelle plage, et qu'est-ce qui compte comme panne ? « Ça ne doit jamais tomber » « 99,9 % en 24/7, hors fenêtre mensuelle de 2 h annoncée »
Une exigence non-fonctionnelle qui ne contient pas de nombre n'est pas une exigence. C'est une intention, et une intention ne se teste pas.

Le SLA, traduit en heures d'indisponibilité

« Toujours disponible » est la réponse la plus fréquente, et la moins exploitable. La manière la plus rapide de rendre la conversation concrète consiste à faire le calcul devant le client, sur un coin de tableau.

1 an  = 365 j x 24 h  = 8 760 h
1 mois (30 j)         =   720 h
99,9 % de 8 760 h  ->  8 760 x 0,001  = 8,76 h d'indisponibilité par an
99,9 % de 720 h    ->    720 x 0,001  = 0,72 h, soit 43,2 min par mois
Niveau Indisponibilité par an Par mois (30 j) Ce que ça impose
99 % 87,6 h 7,2 h Un serveur, des sauvegardes, une astreinte en heures ouvrées
99,9 % 8,76 h 43,2 min Redondance, bascule testée, supervision qui réveille quelqu'un la nuit
99,99 % 52,6 min 4,3 min Aucun point unique de défaillance, bascule automatique, déploiement sans coupure
99,999 % 5,3 min 26 s Multi-site actif/actif, budget et équipe d'exploitation dédiés

Chaque neuf supplémentaire multiplie le coût et change la nature du système, pas seulement son dimensionnement. Passer de 99,9 % à 99,99 % ne s'achète pas avec un serveur de plus : il faut supprimer toute intervention humaine du chemin de reprise, parce que quatre minutes par mois ne laissent pas le temps de lire une alerte.

Le second calcul à faire est celui des dépendances. Ton engagement est plafonné par celui des services dont tu dépends en série.

Service A (99,9 %) -> Service B (99,9 %) -> Service C (99,9 %)
0,999 x 0,999 x 0,999 = 0,997        soit 99,7 %
0,3 % x 8 760 h       = 26,3 h d'indisponibilité par an
Trois dépendances à 99,9 % chacune plafonnent le système à 99,7 %, sans qu'une seule ligne de ton code soit en cause. Un SLA se compose, il ne se déclare pas.

Ce calcul de trente secondes tue plus de faux engagements que n'importe quel argumentaire.

Qui définit le non-fonctionnel, et comment obtenir des chiffres

Sur Le Chantier, le maître d'ouvrage ne connaît pas la contrainte admissible de son terrain, et ce n'est pas son métier. En revanche, lui seul sait combien de personnes travailleront dans l'immeuble et ce qu'on entreposera au sous-sol. Le géotechnicien mesure, l'architecte traduit.

La répartition est identique en logiciel. Le métier détient les chiffres métier. L'architecte détient la traduction en contraintes techniques. Personne ne détient les deux, et personne ne viendra spontanément apporter la première moitié.

Cinq techniques rendent l'exercice praticable.

Pars de l'existant. Si un système est déjà en production, les journaux d'accès, les métriques et les tableaux de bord métier contiennent déjà les réponses. Une facture de licences par utilisateur en dit parfois plus qu'un atelier de deux heures.

Pose la question en unités métier. « Combien de requêtes par seconde ? » ne reçoit jamais de réponse. « Combien de commandes passez-vous un lundi de décembre ? » en reçoit toujours une. La conversion en unités techniques est ton travail, pas le sien.

Propose un chiffre et fais-le corriger. Personne ne sait répondre à une question ouverte, tout le monde sait répondre à une proposition fausse.

sequenceDiagram participant A as Architecte participant M as Responsable métier A->>M: Combien de commandes par jour en décembre ? M-->>A: Beaucoup, c'est notre gros mois A->>M: Disons 8 000 par jour, dont la moitié entre 18 h et 21 h M-->>A: Non, plutôt 20 000, et surtout le lundi A->>M: Donc 20 000 par jour, pic à 3 000 par heure. Je l'écris ? M-->>A: Oui, c'est ça Note over A,M: Un chiffre faux se fait corriger. Une question ouverte reste sans réponse.

Mets un prix en face. « Ça ne doit jamais tomber » redevient négociable quand le second site et l'astreinte permanente apparaissent dans le budget. Le client ne refuse pas la disponibilité, il refuse de la payer sans avoir vu le lien entre les deux.

Écris la réponse et fais-la valider. Une exigence non écrite n'engage personne et se renie sans effort le jour de la recette. Deux lignes dans le document d'architecture, avec la date et la personne qui a donné le chiffre, suffisent.

L'architecte ne devine pas les exigences non-fonctionnelles, il les négocie. Le livrable de cette étape n'est pas une intuition, c'est un tableau de nombres validé par quelqu'un qui a le droit de les valider.

Demande enfin deux horizons : le chiffre du lancement et celui de l'année trois. Les deux figurent dans le document, parce que l'architecture doit tenir le premier sans interdire le second.

Scénario B : HealthCare.gov, le 1er octobre 2013

Le 1er octobre 2013, le marché fédéral américain d'assurance santé ouvre en ligne. La date était connue depuis la promulgation de la loi, trois ans et demi plus tôt. Les premières coupures surviennent deux heures après l'ouverture, et le site reste largement inutilisable pendant des semaines.

Ce cas est précieux parce qu'il est documenté publiquement, en détail, par des organismes indépendants. Le rapport du GAO de juillet 2014, référencé GAO-14-694, décrit une planification et une supervision des contrats défaillantes, avec des exigences qui changent en continu et des coûts qui dérivent. L'étude de cas de l'inspecteur général du ministère de la santé, publiée le 22 février 2016 sous la référence OEI-06-14-00350, décrit un projet éclaté entre de nombreux contractants sans intégrateur système désigné, l'agence CMS estimant tenir ce rôle elle-même sans en avoir l'expérience, et un test de bout en bout complet jamais mené parce que les composants arrivaient trop tard.

Regarde la séquence à travers la grille de ce billet. Le fonctionnel était spécifié abondamment : règles d'éligibilité, calcul des subventions, comparaison des plans, transmission aux assureurs. Des centaines de pages, des années de travail réglementaire.

Le non-fonctionnel, lui, est arrivé en dernier. Une date d'ouverture fixée par la loi, une population éligible de plusieurs millions de personnes recensée par l'administration elle-même, une campagne de communication nationale : tous les ingrédients d'une estimation de charge étaient sur la table, disponibles longtemps à l'avance.

Le test de performance qui tranche la question arrive le 26 septembre 2013, quatre jours et demi avant l'ouverture. Il montre une capacité très inférieure à celle qui était prévue, et il ne reste plus qu'à doubler l'infrastructure en urgence. Le 1er octobre, 250 000 personnes se connectent au même moment, très au-delà de la capacité planifiée.

Le chiffre existait. Il n'a simplement jamais été traité comme une exigence de conception, seulement comme un sujet de test, et le test est arrivé quand il était trop tard pour changer l'architecture.

Après la remise à plat menée en urgence à l'automne 2013, l'administration publie le 1er décembre un rapport d'avancement chiffré : le site tient alors plus de 35 000 utilisateurs simultanés sans tomber, et il a fonctionné plus de 90 % du temps sur la fin novembre.

Reste honnête sur la lecture : cet échec est multi-causal. Calendrier politique contraint, périmètre mouvant jusqu'aux dernières semaines, absence de leadership clair que l'inspecteur général place en tête de ses constats, aucun de ces facteurs n'est réductible à une case oubliée sur une checklist.

Ce que le cas démontre, en revanche, est net. Quand une exigence non-fonctionnelle n'est chiffrée qu'après la conception, elle ne devient pas un risque technique. Elle devient une panne à date fixe, publique, et le chiffre finit toujours par être écrit, mais dans le rapport d'audit.

Points clés

  • Le processus tient en six étapes : exigences fonctionnelles, exigences non-fonctionnelles, composants, stack, conception documentée, support aux équipes. La deuxième est celle qu'on saute, et celle qui coûte le plus cher à rattraper.
  • Une exigence fonctionnelle décrit un comportement, une exigence non-fonctionnelle décrit une contrainte chiffrée. Sans nombre, ce n'est pas une exigence, c'est une intention.
  • Cinq grandeurs couvrent l'essentiel : latence et débit (distincts), charge en courant et en pic, volumétrie sur la durée de rétention, utilisateurs simultanés, SLA.
  • Un SLA se traduit en heures d'indisponibilité et se compose avec celui des dépendances : trois services à 99,9 % en série plafonnent l'ensemble à 99,7 %.
  • Ces chiffres ne se devinent pas. Ils s'obtiennent en partant de l'existant, en parlant en unités métier, en proposant un chiffre faux à corriger, puis en l'écrivant et en le faisant valider.

Dans la série

Palier 1 : Lire le terrain. Domaine : Process.

Pour aller plus loin