Le test d’admissibilité en trois parties pour la RS&DE est clair dans l’abstrait : incertitude technologique, investigation systématique, avancement technologique. En pratique, appliquer ces critères à un tableau de sprint rempli de vrai travail d’ingénierie est plus difficile qu’il n’y paraît.
La chose la plus utile pour la plupart des entreprises logicielles n’est pas une explication plus approfondie des critères. Ce sont des exemples concrets montrant où la ligne tombe et pourquoi. Ces 10 exemples couvrent le spectre de clairement admissible à clairement exclu, avec le raisonnement que l’ARC applique à chacun. Pour le cadre complet d’admissibilité, voir Activités admissibles à la RS&DE pour les entreprises logicielles.
Exemple 1 : Algorithme novel de détection d’anomalies en temps réel
Ce que l’équipe a fait : Une plateforme de commerce en ligne devait détecter les transactions frauduleuses en moins de 50 ms pour ne pas bloquer les flux de paiement légitimes. Les approches existantes de détection de fraude dépassaient soit la cible de latence, soit produisaient des taux de faux positifs qui rejetteraient trop de vrais clients. L’équipe a passé trois mois à investiguer si une approche hybride combinant des bases statistiques avec de l’inférence ML légère pouvait satisfaire les deux contraintes simultanément.
Se qualifie-t-il ? Oui.
Pourquoi : L’incertitude était véritable. Aucune approche publiée n’adressait la combinaison spécifique de cible de latence et de tolérance aux faux positifs sous leur volume de transactions. L’investigation était systématique. L’algorithme résultant adressait un espace de contraintes qu’aucune solution publiée existante ne couvrait.
Exemple 2 : Implémenter un algorithme de recommandation standard
Ce que l’équipe a fait : Une entreprise de détail a ajouté des recommandations de produits utilisant le filtrage collaboratif, une technique bien documentée avec des implémentations open-source extensives.
Se qualifie-t-il ? Non.
Pourquoi : La solution était déterminable par un praticien qualifié à partir des connaissances existantes. Le filtrage collaboratif est bien documenté. Les bibliothèques qui l’implémentent sont largement disponibles.
La ligne : Appliquer des méthodes connues, même habilement, n’est pas de la RS&DE. L’incertitude doit être véritable.
Exemple 3 : Investiguer une corruption mémoire dans un runtime personnalisé
Ce que l’équipe a fait : Une entreprise fintech a construit un runtime de traitement de transactions personnalisé en C++ pour la performance. Après le déploiement, ils ont rencontré une corruption mémoire intermittente causant des erreurs de données silencieuses. L’équipe a passé huit semaines à développer de l’instrumentation personnalisée, tester des hypothèses sur des conditions de course dans leurs structures de données sans verrou et finalement identifier une interaction entre leur allocateur de mémoire et le comportement de cohérence de cache du processeur.
Se qualifie-t-il ? Oui.
Pourquoi : Un problème véritablement difficile nécessitant une investigation originale. L’interaction n’était pas documentée dans la littérature existante. L’investigation était systématique.
Exemple 4 : Correction de bug utilisant des procédures de débogage standard
Ce que l’équipe a fait : Des ingénieurs ont passé 40 heures à déboguer une condition de course dans un service API Node.js. Ils ont utilisé des outils standard, identifié un mutex manquant autour d’un cache partagé et l’ont corrigé.
Se qualifie-t-il ? Non.
Pourquoi : Le processus de débogage a appliqué des outils et méthodes établis à une classe de problème connue. La solution est de la pratique standard.
La distinction : Le travail était techniquement difficile. La difficulté n’est pas le critère. L’incertitude l’est.
Exemple 5 : Construire un format de compression novel pour dispositifs en périphérie
Ce que l’équipe a fait : Une entreprise IoT devait transmettre des données de télémétrie depuis des dispositifs avec 8 Ko de RAM et connectivité 2G. Les formats de compression existants étaient trop coûteux en calcul ou produisaient des ratios de compression insuffisants. L’équipe a passé cinq mois à développer et valider un schéma de compression personnalisé.
Se qualifie-t-il ? Oui.
Pourquoi : L’incertitude était réelle. Aucun format existant ne satisfaisait à la fois le budget mémoire et les exigences de ratio de compression. Le format résultant est véritablement novel.
Exemple 6 : Ajuster la performance d’un modèle ML avec des techniques standard
Ce que l’équipe a fait : Une entreprise SaaS a affiné un modèle de langage pré-entraîné sur son jeu de données de domaine spécifique avec une optimisation d’hyperparamètres standard.
Se qualifie-t-il ? Non.
Pourquoi : L’affinage de modèles pré-entraînés avec l’optimisation d’hyperparamètres est une pratique établie. Appliquer des méthodes connues à de nouvelles données ne crée pas d’incertitude technologique.
L’exception potentielle : Si l’affinage révélait un mode de défaillance spécifique nécessitant une investigation originale, cette investigation spécifique pourrait se qualifier.
Exemple 7 : Concevoir un mécanisme de consensus distribué novel
Ce que l’équipe a fait : Une entreprise d’infrastructure blockchain avait besoin d’un consensus avec finalité en moins de deux secondes tout en tolérant jusqu’à 33 % de défaillances byzantines. Les protocoles existants (PBFT, Tendermint, HotStuff) ne pouvaient pas satisfaire les deux contraintes simultanément à leur échelle réseau requise. Huit mois d’investigation.
Se qualifie-t-il ? Oui.
Pourquoi : L’espace de contraintes n’était pas satisfait par les protocoles publiés existants. L’investigation était rigoureuse et systématique. Le résultat étend l’état des connaissances en systèmes distribués.
Exemple 8 : Intégration d’API existantes pour une nouvelle fonctionnalité
Ce que l’équipe a fait : Une entreprise SaaS de gestion de projet a ajouté une intégration Slack. Trois semaines à étudier la documentation de l’API Slack, implémenter le traitement des webhooks et tester.
Se qualifie-t-il ? Non.
Pourquoi : Intégrer des API bien documentées est de la pratique standard de développement logiciel. Aucune incertitude technologique, aucune investigation requise au-delà de lire et appliquer la documentation existante.
Exemple 9 : Développer un optimiseur de requêtes personnalisé pour données éparses
Ce que l’équipe a fait : Une entreprise d’analytique géospatiale avait besoin de requêtes analytiques sur des données géographiques éparses et irrégulièrement distribuées. Les planificateurs de requêtes de bases de données existants performaient mal parce que leurs modèles de coût assumaient des propriétés de données qui ne tenaient pas. Six mois d’investigation.
Se qualifie-t-il ? Oui.
Pourquoi : L’hypothèse était spécifique et testable. L’échec des planificateurs génériques était documentable. Le résultat représente un véritable avancement.
Exemple 10 : Investigation échouée qui n’a produit aucune solution fonctionnelle
Ce que l’équipe a fait : Une entreprise de technologie de santé a investigué si le raisonnement hybride neuro-symbolique pouvait améliorer la précision diagnostique au-delà de ce que les approches ML pures produisaient. Quatre mois à tester cinq architectures hybrides différentes. Aucune n’a surpassé le modèle ML existant. L’investigation a été abandonnée.
Se qualifie-t-il ? Oui.
Pourquoi : La RS&DE n’exige pas le succès. Elle exige une investigation véritable. L’incertitude technologique était réelle. L’investigation était systématique. Découvrir que les approches hybrides existantes ne surpassent pas leur base de référence ML sur cette tâche est en soi une connaissance technique. L’ARC reconnaît explicitement que les expériences échouées peuvent se qualifier.
Lire le pattern
En regardant à travers ces 10 exemples, les cas admissibles partagent trois propriétés.
L’incertitude était véritable et spécifique. Pas « nous n’étions pas sûrs que ça marcherait » mais « cette combinaison spécifique de contraintes n’est pas adressée par les approches publiées, et voici la preuve ».
L’investigation était structurée. Pas « nous avons essayé des trucs » mais une progression documentée d’hypothèses testées, résultats observés, approches affinées ou éliminées.
La documentation existait au moment. Le narratif de ce qui a été essayé et pourquoi a été capturé durant l’investigation, pas reconstruit de mémoire au moment du dépôt.
Les cas non admissibles échouent sur le premier critère : la réponse était connaissable à partir des ressources existantes. Appliquer des algorithmes connus, implémenter des API documentées, ajuster des architectures de modèles établies. Ce sont des activités d’ingénierie logicielle qualifiée, pas de la recherche technologique.
L’erreur RS&DE la plus courante que les entreprises logicielles font est de déposer basé sur l’effort et la complexité plutôt que l’incertitude et l’investigation. Le travail difficile n’est pas de la RS&DE. La recherche l’est.
Besoin d’aide pour identifier le travail admissible dans votre équipe d’ingénierie ? Parlez à notre équipe pour automatiser la documentation RS&DE depuis vos outils de développement.