Ce qu'on peut dire d'un outil que personne n'a encore utilisé

On a construit un outil qui transforme une offre d'emploi en entraînement. Il tourne, il tient la charge, il est confiné. Et personne ne s'en est encore servi pour décrocher un poste. Voici ce qu'on peut affirmer, ce qu'on ne peut pas, et pourquoi la différence compte plus que le reste.

1. Ce que fait l'outil

Vous collez le texte d'une offre d'emploi. L'outil en extrait les compétences réellement demandées, construit un parcours, et vous interroge dessus — questions à choix multiples, estimations chiffrées, arbitrages d'architecture, exercices de récit. Chaque réponse s'accompagne d'un pourquoi. Ce que vous ratez revient plus souvent ; ce que vous maîtrisez s'espace. Une compétence tenue assez longtemps devient un quartier de blason.

La banque d'exercices écrite à la main couvre douze compétences pour quarante-six exercices : nuage, conteneurs, infrastructure déclarative, agents, recherche augmentée, coût, sécurité, données, mise en production de modèles, et la façon dont un entretien se déroule réellement aux États-Unis. Pour tout le reste — un poste commercial, un poste juridique, un métier qu'on n'avait pas prévu — l'outil peut fabriquer les exercices, à condition que l'utilisateur fournisse sa propre clé d'API. Sans clé, il reste la banque écrite à la main.

2. Ce qu'on a mesuré : la charge

Le serveur stocke ses données en SQLite synchrone. Ce mot décide de tout : chaque requête bloque la boucle d'événements. Pas de file, pas de parallélisme. Une seule requête lente met tout le monde en attente, y compris la page qui dit si le service va bien.

En temps normal ça ne se voit pas — les requêtes durent moins d'une milliseconde. Mais l'interface comporte une carte animée qui interroge le serveur en boucle. Un onglet oublié ouvert une nuit, ou dix personnes en même temps, et on découvre la limite de la mauvaise façon.

On a donc lancé trois cents requêtes simultanées sur l'instance en ligne. Résultat :

Le chiffre le plus instructif est le zéro. Il dit que les deux protections sont dans le bon ordre : la moins chère coupe en premier, et la plus brutale reste en réserve. Si on avait vu l'inverse, il aurait fallu revoir les réglages — pas ajouter une troisième protection.

3. Ce qu'on a mesuré : le confinement

La première version tournait directement sur la machine, sous le compte d'administration. Ce compte peut devenir super-utilisateur sans mot de passe et pilote les conteneurs. Autrement dit : une faille dans un exercice à choix multiples donnait la machine entière.

L'application a donc son image, et le conteneur qui en sort n'a presque rien : utilisateur non privilégié, système de fichiers en lecture seule, toutes les capacités du noyau retirées, interdiction d'en regagner, 512 Mo de mémoire, 256 processus, aucun port publié — il n'est joignable que par le serveur d'entrée — et aucun accès au pilote de conteneurs. Le seul endroit où il peut écrire est le volume qui contient sa base.

Question qu'on aurait dû se poser bien plus tôt : ce n'est pas « combien de requêtes ça tient », c'est « si ce processus tombe, jusqu'où va l'attaquant ». Les deux questions ont l'air voisines. Elles ne mènent pas au même travail.

4. Le défaut qui nous a le plus appris

L'outil devait reconnaître les compétences dans le texte d'une offre. La première version cherchait un mot dans une chaîne, tout simplement. 

// Ce que faisait la première version
if (texte.toLowerCase().includes(motif)) { ... }

Sur une offre d'architecte en intelligence artificielle, elle a rapporté une compétence de gestion d'actifs industriels. Le motif était eam — et il est à l'intérieur de team, mot qui revenait six fois dans l'annonce. Plus tard, le même défaut a rangé une offre de « négociation commerciale » dans les agents intelligents, parce que ia est à l'intérieur de négociation. 

// Ce qu'elle fait maintenant : un mot, pas un morceau de mot
const re = new RegExp('(?<![a-z0-9])' + echappe(motif) + '(?![a-z0-9])', 'i')
return re.test(texte)

Ce défaut mérite d'être raconté parce qu'il ne plantait pas. Il ne remontait aucune erreur, ne remplissait aucun journal. Il produisait un résultat plausible, poliment, à chaque fois. C'est la catégorie de défaut la plus coûteuse : celle qui ne demande rien et qu'on ne trouve qu'en regardant le résultat de près, avec une offre dont on connaît déjà la bonne réponse.

5. Ce qu'on n'a pas mesuré

Tout ce qui précède est vrai et vérifiable. Rien de tout cela ne dit si l'outil sert à quelque chose.

Personne ne l'a encore utilisé pour préparer un entretien réel. Aucun candidat n'a été reçu, ni recalé, après s'être entraîné dessus. On ne sait pas si la répétition espacée tient sur trois semaines quand la motivation retombe. On ne sait pas si les exercices écrits à la main ressemblent aux questions réellement posées. On ne sait pas si les exercices fabriqués pour un métier qu'on n'avait pas prévu valent quoi que ce soit.

La seule mesure qui compte serait : quelqu'un s'est entraîné, et ça a changé l'issue de son entretien. On ne l'a pas. On ne l'aura pas avant des semaines, et il faudra plus d'une personne pour que le chiffre veuille dire quelque chose.

On aurait pu écrire cet article sans ce paragraphe. Il aurait été plus flatteur et tout aussi exact. Il aurait juste laissé croire qu'une latence de 10 ms au 99e centile prouve qu'un outil aide quelqu'un — et ces deux choses n'ont rien à voir.

6. Ce qu'on en retient

🔭