Comment reconnaître un bon dossier RS&DE en développement logiciel

Toute entreprise qui « fait du logiciel » ne fait pas de la RS&DE. À l'inverse, beaucoup de bons dossiers passent inaperçus parce que le client décrit son travail en termes d'affaires plutôt qu'en termes techniques. Votre rôle n'est pas de juger le code, mais de repérer la présence d'une démarche expérimentale face à une incertitude technologique. Quelques questions et signaux suffisent à orienter la décision.

Le critère central : l'incertitude technologique

La RS&DE ne récompense pas l'effort, la nouveauté commerciale ou la complexité perçue. Elle récompense le fait d'avoir affronté une incertitude technologique qu'on ne pouvait pas lever en appliquant simplement des pratiques connues. La question à garder en tête : « Un développeur compétent du domaine aurait-il su d'avance comment y arriver ? » Si la réponse est non, il y a matière à creuser.

Cinq signaux d'un bon dossier

• L'équipe a tâtonné. Plusieurs approches ont été essayées, comparées, parfois abandonnées. Le projet n'a pas suivi une ligne droite.
• On parle de limites techniques. Performance, montée en charge, latence, précision d'un modèle, contraintes matérielles ou d'intégration qui résistaient aux solutions habituelles.
• La documentation ou les bibliothèques existantes ne suffisaient pas. L'équipe a dû développer quelque chose là où l'outillage du marché s'arrêtait.
• Il y a eu des échecs réels. Des versions qui ne tenaient pas la charge, des résultats sous les attentes, des réécritures. C'est un bon signe, pas un mauvais.
• Les développeurs s'animent quand ils en parlent. Le « vrai » problème technique est souvent celui dont l'équipe parle avec passion ou frustration.

Cinq signaux qui doivent vous rendre prudent

• « On a juste assemblé des outils existants. » Intégrer des composants éprouvés selon leur usage prévu n'est généralement pas de la R&D.
• Tout le récit est commercial. Si le client ne décrit que des fonctionnalités et des bénéfices clients, sans aucun obstacle technique, le dossier est fragile.
• « C'était long, mais pas vraiment compliqué. » Le volume de travail ne crée pas l'admissibilité ; l'incertitude, oui.
• Configuration et personnalisation. Paramétrer une plateforme, brancher des API documentées ou styliser une interface relève rarement de la RS&DE.
• Aucune trace. Pas de code versionné, pas de tickets, pas de notes : même un bon projet devient difficile à défendre.

Un raccourci utile : demandez « Qu'est-ce qui aurait pu ne pas marcher, et pourquoi n'étiez-vous pas certains que ça marcherait ? » La qualité de la réponse révèle, en une minute, s'il y a un dossier.

Bon projet n'égale pas toujours bon dossier

Un projet peut comporter de la vraie R&D et rester difficile à réclamer si la preuve est inexistante ou si l'incertitude est noyée dans du travail de routine. À l'inverse, un projet modeste mais bien circonscrit, avec une trace claire des essais, donne souvent un dossier plus propre. La capacité à isoler et documenter la portion admissible compte autant que la présence d'incertitude.

En cas de doute, validez avant d'investir

Quand un dossier est ambigu (c'est fréquent en SaaS, en plateformes et en IA), une courte conversation technique avec l'équipe du client lève le doute rapidement. C'est précisément ce que je fais pour les cabinets : un avis technique de premier niveau qui vous évite d'engager du temps sur un dossier fragile, ou qui confirme qu'il vaut la peine d'aller plus loin.