Dans Dr. Stone, Senku reconstruit la civilisation depuis zéro. Le moment que je préfère n'est pas celui où il fabrique de la poudre à canon : c'est celui où il doit d'abord établir des unités de mesure. Sans étalon partagé, aucune recette ne se transmet, aucune quantité ne se reproduit. La mesure précède la science.
J'ai revécu ce moment en construisant le moteur de prix de Pla'nif, une application de planification de repas camerounais. Je pensais coder une multiplication. J'ai passé l'essentiel du temps à répondre à une question apparemment triviale : combien coûte un ingrédient ?
Le problème que personne ne voit venir
Une recette dit : « 3 plantains mûrs ».
Le marché de Bafoussam vend : « le tas de plantains à 500 FCFA ».
Entre les deux, il n'y a pas de conversion évidente. Un tas contient entre quatre et sept plantains selon le vendeur, la saison et ta capacité à négocier. Un plantain pèse entre 150 et 400 grammes.
Multiplie ce problème par deux cents ingrédients, et tu comprends pourquoi les applications de planification de repas conçues en Europe sont inutilisables ici. Elles supposent un code-barres, un poids net imprimé et un prix au kilo affiché. Trois hypothèses fausses sur un marché africain.
Le même écart apparaît partout :
- Les feuilles se vendent à la botte. Une botte de ndolé, ce n'est pas une unité de masse, c'est une unité de main.
- L'huile de palme se vend au litre, se cuisine à la cuillère, et se compte au poids dans les calculs nutritionnels. Trois systèmes pour un seul produit.
- Le poisson fumé se vend à la pièce, mais la pièce varie du simple au triple.
L'unité canonique, et pourquoi elle sauve tout
La décision structurante a été celle-ci : chaque ingrédient possède une unité canonique unique, et tout le reste est une conversion vers elle.
Le plantain est stocké en grammes. Toujours. Une recette qui demande « 3 plantains » est convertie via un grams_per_piece propre à l'ingrédient. Un prix relevé « le tas à 500 FCFA » est converti via un poids de tas moyen.
Ce que ça change : il n'existe qu'un seul endroit où une conversion peut être fausse. Avant cette décision, j'avais des conversions éparpillées dans le code d'affichage, dans le calcul de coût, dans la liste de courses — et bien sûr elles divergeaient.
Le principe général mérite d'être retenu au-delà de la cuisine : quand tu manipules des quantités hétérogènes, convertis à l'entrée, stocke en canonique, reconvertis à l'affichage. Jamais de calcul sur des unités mélangées. Le bug le plus coûteux que j'aie corrigé dans ce projet venait d'un ingrédient stocké en litres pendant que la formule le traitait comme des millilitres — un facteur mille sur le prix affiché, dans une application dont l'argument de vente est justement le prix.
Le volume et le poids ne se convertissent pas sans densité
Deuxième piège, plus sournois : « 50 cl d'huile », ça pèse combien ?
Pas 500 grammes. L'huile de palme a une densité d'environ 0,91 — donc 455 grammes. L'écart de 10 % paraît négligeable jusqu'à ce qu'il se propage sur toute une semaine de menus et fasse dériver un budget.
Chaque ingrédient porte donc une density_g_per_ml. Les ingrédients secs n'en ont pas besoin, les liquides oui, et les poudres sont un cas à part — la densité de la farine dépend de son tassement, ce qui explique pourquoi les recettes de pâtisserie sérieuses donnent des grammes et pas des tasses.
C'est un détail. Les logiciels utiles sont faits de détails de ce genre, accumulés.
Le prix dépend de l'endroit, et souvent on ne l'a pas
Un kilo de tomates à Douala, à Bafoussam et à Garoua, ce ne sont pas les mêmes prix. Une application de budget qui ignore ça donne des chiffres faux, donc inutiles.
Mais on ne peut pas exiger d'avoir un relevé de prix pour chaque ingrédient dans chaque ville. La couverture serait ridicule au démarrage, et l'application afficherait « prix indisponible » partout — la pire expérience possible.
La règle de repli retenue :
- Prix relevé dans la ville de l'utilisateur → on l'utilise.
- Sinon, médiane nationale de cet ingrédient → on l'utilise, en signalant l'approximation.
- Sinon, l'ingrédient est marqué comme non estimable et exclu du total, sans le faire disparaître de la recette.
La médiane, pas la moyenne. Un relevé aberrant — une erreur de saisie, un prix de supérette pour touristes — décale la moyenne et laisse la médiane intacte. Sur des données saisies par une communauté, la médiane est presque toujours le bon choix.
Le troisième cas est le plus important pour la confiance : mieux vaut afficher « environ 2 300 FCFA (2 ingrédients non estimés) » qu'un total faux présenté comme exact. L'utilisateur qui découvre au marché que ton estimation était à 40 % ne revient pas.
Un repas n'est pas une recette
Le dernier obstacle n'était pas de la mesure, mais de la modélisation culturelle.
Les applications de planification supposent : un repas = une recette. Une lasagne, un curry, un bol.
Un repas camerounais, c'est très souvent une sauce et un accompagnement. Du ndolé avec du plantain. De l'okok avec du bâton de manioc. Générer un menu hebdomadaire en tirant sept recettes au hasard produit des résultats absurdes — sept sauces sans féculent, ou trois accompagnements d'affilée.
Il a fallu introduire un type de plat, et des paires sauce/accompagnement cohérentes. Le générateur ne tire plus des recettes : il compose des repas.
C'est le genre de chose qu'aucune spécification technique ne contient, parce que c'est une évidence pour qui a grandi ici et invisible pour qui n'y a pas grandi. Un développeur qui code pour un marché qu'il ne connaît pas produira une application qui marche et que personne n'utilise.
Le problème de fond : les logiciels supposent un contexte
C'est le point que je veux vraiment défendre.
Toute bibliothèque, tout framework, tout composant que nous utilisons transporte des hypothèses sur le monde. Un sélecteur de date suppose un calendrier grégorien. Un champ d'adresse suppose une rue et un code postal. Un formatteur de prix suppose deux décimales — le franc CFA n'en a aucune. Un champ téléphone suppose un format.
Ces hypothèses sont invisibles tant que tu construis pour le contexte qui les a produites. Elles deviennent des bugs dès que tu en sors.
Ce que je fais désormais systématiquement, sur tout projet destiné à un marché africain :
- Lister les hypothèses cachées avant de choisir une bibliothèque. Formats de nombre, d'adresse, de téléphone, de nom — beaucoup de gens n'ont pas de « prénom, nom » au sens occidental.
- Aller sur le terrain. Une heure au marché de Bafoussam a modifié davantage la modélisation de Pla'nif que trois jours de conception sur papier.
- Coder le cas « je ne sais pas ». L'absence de donnée est un état légitime, pas une exception à masquer.
Ce dernier point est le plus transposable. Nos schémas de données sont pleins de colonnes NOT NULL qui expriment un vœu plutôt qu'une réalité. Le monde est incomplet ; les modèles qui le nient produisent des logiciels qui mentent.
Ce qu'il reste à faire
Le moteur fonctionne, les estimations sont cohérentes avec les prix pratiqués. Mais la qualité des données reste le vrai chantier : des titres de recettes en doublon, des unités mal saisies, une couverture de prix inégale selon les villes.
C'est la leçon la moins glamour et la plus fiable de ce projet : un algorithme correct sur des données médiocres produit des résultats médiocres. Le temps passé à nettoyer les données rapporte davantage que le temps passé à raffiner la formule.
Pla'nif est décrit sur sa fiche projet. Si tu construis un produit dont le cœur est une modélisation de terrain, on peut en discuter.