LOGICIELS · SAAS · ALGORITHMES · IA

Développement de logiciels : quels projets sont éligibles à la WBSO ?

Bij software is de grens tussen bouwen en ontwikkelen het lastigst. RVO kijkt niet naar het systeem, maar naar het technische probleem en het nieuwe werkingsprincipe dat u in code realiseert. Ook als zelfstandige zonder personeel komt u in aanmerking — zie WBSO voor zzp’ers. Softwareontwikkeling kan voor WBSO in aanmerking komen wanneer u zelf technisch nieuwe programmatuur ontwikkelt, daarbij concrete programmeertechnische knelpunten oplost en het nieuwe informatietechnologische werkingsprincipe vastlegt in een formele programmeertaal. Alleen een nieuwe functionaliteit, applicatie of gebruikerservaring is niet voldoende.

PAR PETER KLAREN · MIS À JOUR LE 19 SEPTEMBRE 2026 · SOURCE : GUIDE RVO 2026

SUR CETTE PAGE

Quand le développement logiciel est-il éligible à la WBSO ?

Il doit exister des risques ou incertitudes techniques et la solution ne doit pas pouvoir être réalisée simplement avec la technologie existante. Pour les logiciels, RVO vérifie explicitement si vous développez vous-même des logiciels techniquement nouveaux dans un langage formel, nommez des problèmes logiciels et les résolvez vous-même.

Les logiciels doivent être développés dans un langage de programmation formel

Un modèle, une architecture, un algorithme ou une description technique peut être intellectuellement très novateur, mais ne relève pas encore automatiquement du développement logiciel WBSO. Le travail de développement qualifiant doit être réalisé en logiciels dans un langage formel. Pour un algorithme aussi : le fait de le formuler ne suffit pas ; il doit être effectivement réalisé en logiciels.

Techniquement nouveau versus fonctionnellement nouveau

C’est la délimitation la plus importante pour la WBSO logicielle. RVO rend cette distinction explicite : construire une nouvelle fonctionnalité sur la base d’une technologie disponible n’est pas un logiciel techniquement nouveau.

Votre produit logiciel n’est pas le problème de projet WBSO

RVO donne elle-même l’exemple : le projet est un système qui planifie des itinéraires ; le problème informatique est que l’algorithme existant n’atteint pas les spécifications requises.

Insuffisant : « Nous développons une nouvelle plateforme SaaS. »

Concret, oui : « La structure de recherche actuelle exige une comparaison linéaire de 15 millions d’enregistrements, ce qui porte le temps de réponse au-delà de 800 ms ; les méthodes d’indexation disponibles ne suffisent pas dans notre limite de mémoire. »

Quand le développement d’algorithmes peut-il être WBSO ?

Ce n’est pas l’invention d’un algorithme qui est déterminante, mais le développement logiciel avec lequel un verrou technique est résolu. Catégories pertinentes notamment :

Performance et scalabilité

Une approche éprouvée échoue-t-elle démontrablement à vos volumes ? Des verrous concrets et mesurables renforcent une demande :

Nuance importante : une exigence de performance élevée n’est pas en soi une WBSO. L’essentiel est que les techniques existantes échouent de manière démontrable et que vous deviez développer vous-même une solution logicielle techniquement nouvelle.

Systèmes distribués et traitement temps réel

La WBSO peut devenir pertinente pour de nouvelles solutions à :

Attention : appliquer Kafka, Kubernetes, Redis, la réplication PostgreSQL ou un protocole de consensus existant n’est pas en soi un logiciel techniquement nouveau. L’incertitude technique doit résider dans ce que vous développez vous-même de nouveau, pas dans le fait que l’architecture est complexe.

Logiciels embarqués

Les logiciels embarqués peuvent bien correspondre aux critères WBSO lorsque des contraintes strictes de timing, de mémoire, de consommation d’énergie ou d’interaction matérielle conduisent à des verrous logiciels concrets sans solution connue disponible.

RVO mentionne elle-même comme exemple la synchronisation temps réel et le réglage fin de machines avec des logiciels propres en C comme S&O possible.

IA, machine learning et vision par ordinateur

RVO donne dans le Guide 2026 l’exemple d’une entreprise qui utilise TensorFlow pour entraîner un modèle : comme aucun développement logiciel propre n’a lieu, ce n’est pas un logiciel techniquement nouveau. En même temps, RVO mentionne des bots/techniques d’IA développés en propre en Python et R comme S&O possible.

API, bases de données et intégration

Intégrer de manière techniquement nouvelle des composants logiciels existants ou les faire collaborer peut être du S&O possible, mais ces composants doivent alors être principalement développés en propre et déjà appliqués dans l’entreprise.

Contraste RVO : la synchronisation temps réel de machines via des logiciels C propres peut être du S&O possible, tandis que connecter des machines via des API disponibles n’est pas un logiciel techniquement nouveau.

Qu’est-ce qui relève généralement de la WBSO logicielle et qu’est-ce qui n’en relève pas ?

RVO considère explicitement l’apprentissage d’un environnement de développement nouveau pour l’entreprise comme non-S&O : la « première utilisation » est considérée comme une phase d’apprentissage.

Exemples de développement logiciel WBSO

Les situations suivantes illustrent où le développement logiciel peut devenir techniquement incertain. Ce sont des situations d’exemple anonymisées, pas d’affirmations sur des clients spécifiques.

Consultez aussi Exemples WBSO et le cas WBSO détaillés.

Comment décrivez-vous les logiciels dans une demande WBSO ?

RVO demande dans le formulaire de projet officiel explicitement les langages, environnements de développement, outils, nouveauté technique, risques et incertitudes.

1. Objectif technique : que faut-il rendre techniquement possible ?
2. Goulot logiciel : qu’est-ce qui ne réussit pas techniquement ?
3. Technique existante : pourquoi les frameworks/bibliothèques ne résolvent-ils pas cela ?
4. Voie de solution : qu’allez-vous développer techniquement vous-même ?
5. Incertitude technique : pourquoi n’est-il pas sûr au préalable que cela fonctionne ?
6. Logiciels : dans quel langage/environnement le principe est-il réalisé ?

Utilisez le guide étendu pour une description de projet WBSO solide et le plan par étapes pour Déposer une demande WBSO.

Gestion de projet pour les logiciels

L’historique Git, les tickets et les conceptions techniques sont une bonne base. Étendez cela avec :

• commits et pull requests ;
• suivi de tickets ;
• expériences techniques ;
• résultats de benchmark ;
• profils de performance ;
• logs de test ;
• architecture decision records ;
• prototypes ;
• résultats de mesure ;
• documentation des voies de solution échouées.

Tout n’a pas besoin d’être présent. L’essentiel est que l’administration rende visibles quelles activités techniques ont réellement été accomplies. Consultez les exigences complètes sous Gestion administrative des projets WBSO.

Logiciels WBSO en 2027 : que pourrait changer ?

Le gouvernement étudie actuellement comment la WBSO peut mieux s’aligner sur les évolutions de l’IA et du développement logiciel moderne. Les ajustements précis ne sont pas encore fixés. Dès que de nouveaux critères sont connus, nous actualisons cette page.

Consultez toutes les modifications WBSO annoncées pour 2027 →

Questions fréquentes sur les logiciels WBSO

SOURCES ET VÉRIFICATION DU CONTENU

RVO — Guide WBSO 2026

Contrôlé par Peter Klaren, spécialiste WBSO depuis 2004. Dernière mise à jour de fond : 21 septembre 2026.