Le verrou technique en cinq exemples de projets logiciels

L'équipe doit ingérer des flux industriels avec des pics à 300 000 événements par seconde, une latence de bout en bout sous 500 millisecondes et l'ordre conservé par clé. Les moteurs publiés tiennent 40 000 événements par seconde sur cette topologie ; rien ne dit qu'un partitionnement par clé composite peut tenir la charge sans perdre l'ordre. La question est posée avant les travaux, deux hypothèses sont testées, la première sature la mémoire à 120 000 événements par seconde et est abandonnée : c'est une démarche expérimentale sur un verrou.

Ramener la latence de recherche de 800 à 200 millisecondes sur 50 millions de documents, avec un rappel supérieur à 95 % et des insertions continues. Les index publiés supposent un index figé ou perdent en rappel à cette échelle. La question « une quantification incrémentale peut-elle conserver le rappel avec des insertions continues ? » n'a pas de réponse dans la littérature : verrou. La bibliographie citée doit montrer ces limites, article par article.

Passer d'une base à une autre, réécrire les requêtes, migrer les données sans interruption de service : long, risqué, coûteux, mais entièrement documenté par les éditeurs et la communauté. Un ingénieur compétent sait que c'est faisable et comment. Le résultat est certain, seule la charge est incertaine : développement, pas recherche.

Connecter l'application à une API de paiement, gérer les retours, les remboursements et la conformité : la documentation existe, les bibliothèques existent, des milliers d'entreprises l'ont fait. Même avec des contraintes fortes, il n'y a pas d'incertitude scientifique. Déclarer ce projet au CIR expose à une requalification certaine.

Détecter des anomalies sur des séries temporelles industrielles très bruitées, avec très peu d'exemples étiquetés. Si l'équipe a appliqué une méthode publiée et réglé ses paramètres, il n'y a pas de verrou. Si les méthodes publiées atteignent des taux de faux positifs incompatibles avec l'usage, que l'équipe l'a mesuré, formulé la question, tenté une architecture combinant apprentissage faiblement supervisé et connaissance du procédé, et documenté ses échecs, il y a un verrou. Ce sont les pièces qui tranchent : un rapport d'essais daté vaut plus qu'un paragraphe de conviction.

Dans les deux projets éligibles, la question était formulée avant les travaux, l'état de l'art disait pourquoi elle restait ouverte, et des essais mesurés ont tenté d'y répondre, avec des échecs. Dans les deux projets inéligibles, personne ne doutait du résultat. Le cinquième montre que la qualification ne se décide pas sur le sujet du projet mais sur ce que les traces prouvent.