Recherche axée sur les PME grâce à la R&D collaborative - le projet PRiMa-Q

Les petites et moyennes entreprises (PME) sont les principaux moteurs de nombreuses économies dans le monde, en particulier dans les pays européens où les PME embauchent environ les deux tiers de la population et génèrent 58% de la valeur ajoutée totale. Cependant, les PME manquent généralement de ressources à la fois en termes de temps et d’expertise pour effectuer suffisamment de R&D afin de rester à jour dans un monde évoluant rapidement. Ceci est particulièrement vrai pour les TIC qui sont maintenant requises dans tous les domaines pour une opération réussie, par ex. industrie 4.0, logistique, eHealth, énergie, etc.

CORNET est un programme de R&D où des agences nationales/régionales combinent leurs financements pour accroître la compétitivité des PME. Dans ce blog, nous partageons notre expérience pour mener à bien de tels projets dans le but de répondre efficacement les besoins des PME et de leur transférer les résultats. Nous essayons de fournir quelques réponses aux questions suivantes :

• comment gérer le projet en utilisant une approche itérative (d’inspiration Agile), compte tenu de la nécessité de rassembler les besoins, de développer une solution pratique et de la valider dans un délai court (2 ans).
• comment rassembler efficacement les exigences par différents moyens tels que des entretiens avec des entreprises et un sondage en ligne.
• comment construire une vision commune à la fois du problème et de la solution en utilisant des techniques adéquates telles que des modèles et des scénarios
• comment gérer le prototypage et la validation dans la courte durée du projet et afin de maximiser les chances d’exploitation.

Notre expérience repose principalement sur deux projets CORNET (3 partenaires R&D et environ 10 PME) et également sur des projets CWALITY (CETIC + PME). Dans le cadre de ce document, nous aborderons le PRIMa-Q en répondant à la nécessité d’une gestion de projet axée sur le risque. Nous avons choisi ce projet parce que son objectif est précisément lié à la gestion de projet et, dans une certaine mesure, le projet lui-même est une étude de cas. En général, les PME sont confrontées à de nombreux problèmes pouvant entraîner des défaillances, des retards ou des dépassements de budget dans leurs projets. Ces problèmes ne sont pas limités aux PME, mais ils peuvent être très néfastes voire mortels pour eux en raison de leur taille, de leur maturité ou de leurs ressources limitées. La gestion de projet est particulièrement reconnue comme un élément essentiel dans le secteur des technologies de l’information où environ la moitié des projets sont contestés et 20% se soldent toujours par un échec. Ce problème tend à s’étendre à tous les domaines car la plupart des produits et services sont de plus en plus connectés et s’appuient sur l’Internet des objets. Le processus de production dépend également de plus en plus de l’IT avec l’évolution vers les usines connectées ("smart manufacturing" ou "Industrie 4.0").

Adopter une approche itérative (d’inspiration agile)

Afin de rester concentré sur les besoins des PME dans un projet relativement court (2 ans), il est fortement recommandé de suivre une approche itérative. Les principes Agiles et leurs quatre valeurs fondamentales sont totalement alignés sur les besoins des PME et peuvent conduire le projet :

• se concentrer sur les personnes et les interactions plutôt que sur le processus et les outils.
• cibler un logiciel de travail plutôt qu’une documentation exhaustive.
• collaborer avec le client plutôt que de s’en tenir à une relation contractuelle.
• s’adapter aux changements plutôt que suivre aveuglément un plan.

Ces valeurs sont affinées en 12 principes. Ces principes sont mis en œuvre dans des méthodes concrètes spécifiques telles que Scrum (illustré dans l’image suivante), la programmation extrême (XP), la programmation conduite par le comportement (BDD). Cependant, de telles méthodes ne devraient pas être appliquées aveuglément aux projets de R & D, car le calendrier, le niveau d’allocation des ressources et la cible de TRL sont différents des projets de développement purs. Cependant, des principes clés tels que la concentration sur les besoins, la validation précoce, l’adaptation au changement s’appliquent.

Scrum Agile process.

Notre objectif ici n’est pas de pointer vers une méthode spécifique, mais plutôt de mettre en évidence un certain nombre d’actions concrètes qui peuvent être mises en œuvre dans le cadre d’un projet de R & D à court terme. Dans le reste de cette section, nous décrivons comment les concepts principaux ont été mis en œuvre pour notre projet et peuvent inspirer d’autres projets du même type.

• Initialisation du projet (backlog). Au début du projet, il y a une phase typique où les partenaires doivent apprendre à se connaître, mettre en place l’organisation du projet, collecter les exigences avec les utilisateurs finaux et convenir de la portée initiale du projet. Cela peut généralement durer de un à six mois. Pendant ce temps, cependant, certains développements techniques liés à l’infrastructure de projet requise peuvent progresser en parallèle
• Durée de l’itération. Dans le développement commercial, les sprints durent habituellement 1 ou 2 semaines. Dans un contexte typique de R & D, les équipes ont besoin de plus de temps pour réaliser des unités de travail spécifiques parce que les projets sont souvent entrelacés avec un certain nombre de tâches plus opérationnelles et à court terme qui alimentent indirectement la recherche (transfert de technologie, publication). Une itération typique durera entre 1 mois et 3 mois selon le projet. Au fur et à mesure que le projet progressera, il y aura probablement moins de recherche et plus de développement, ce qui rapprochera le projet d’un développement classique. À ce moment, le projet visera également à fournir un démonstrateur bien défini. Cela entraîne généralement des sprints raccourcis vers la fin du projet.
• Standups peuvent se concentrer sur un seul partenaire ou un sous-ensemble de partenaires impliqués dans une tâche spécifique. Dans notre cas, les réunions « stand-up » sont en réalité de courtes réunions d’une heure qui ont lieu chaque semaine à un créneau horaire spécifique. En outre, une téléconférence est également organisée pour se synchroniser avec les autres partenaires, généralement deux fois par semaine.
• Les débriefings d’itération peuvent se produire lors de téléconférences plus longues et à l’occasion de réunions de projet physiques entre partenaires et / ou utilisateurs finaux. Ces réunions ont généralement lieu tous les 3 mois à 6 mois au plus tard (dans notre cas, il est nécessaire pour des raisons administratives). Une bonne idée est de mélanger le type de réunions, l’une avec le comité des utilisateurs locaux pour un sprint donné et l’autre avec les partenaires du sprint suivant / suivant. Des réunions avec le comité des utilisateurs permettront de s’assurer que les utilisateurs finaux sont tenus au courant afin de s’assurer que le projet répond à leurs besoins et leur apporte de la valeur. Les rencontres avec les partenaires sont également importantes pour assurer l’accord sur les objectifs et la planification des prochains sprints.

Rassembler des exigences réalistes

Comme la plupart des projets orientés PME, notre projet est assez court (2 ans). Pour un tel projet, il est risqué de de se donner des objectifs R&D très pointus mais plutôt de se concentrer sur des objectifs concrets apportant de la valeur aux PME qui sont rapidement identifiées et acceptées. Idéalement, ces objectifs devraient déjà être énoncés dans la proposition, car cela fait partie des critères d’évaluation pour un tel projet. Cependant, afin d’affiner les exigences, une tâche dédiée est généralement proposée au cours des tous premiers mois du projet (voir la phase d’initialisation ci-dessus). Différents moyens peuvent être utilisés pour parvenir à un rassemblement efficace des besoins, dans notre cas, nous avons utilisé des réunions avec les utilisateurs finaux, un sondage en ligne et un raffinement supplémentaire de l’état de l’art.

Réunions avec les utilisateurs finaux

Un projet CORNET dispose d’un comité d’utilisateur final obligatoire. La première réunion sera généralement axée sur l’explication des objectifs du projet aux représentants des PME et l’identification des besoins avec eux. Il est important de rassembler des exigences qui peuvent être généralisées afin d’avoir un bon potentiel d’exploitation mais aussi d’identifier un certain nombre de cas d’utilisation concrets qui conduiront à une validation concrète. A cet effet, différentes techniques peuvent être utilisées comme regarder les systèmes existants des utilisateurs, organiser une session de brainstorming, collecter des user stories, etc.

Effectuer un sondage en ligne

Afin de rassembler les besoins à une plus grande échelle que l’utilisateur directement impliqué dans le projet, il est utile de concevoir un sondage en ligne qui ne devrait pas être trop long à remplir. Cela devrait normalement durer de 10 à 15 minutes et éviter les questions trop complexes qui amèneront l’utilisateur à quitter l’enquête. Il peut d’abord être utilisé avec les utilisateurs déjà contactés afin de s’assurer qu’il est bien conçu avant de le diffuser à plus grande échelle en utilisant différents canaux et relais tels que l’organisation sectorielle, les réseaux sociaux professionnels et les groupes d’intérêts spéciaux. Une telle enquête devrait rassembler quelques informations pour caractériser le répondant, les pratiques actuelles et identifier / valider les exigences à travers des questions fermées mais aussi quelques questions ouvertes (pas trop). Bien que par défaut une telle enquête devrait être anonyme, elle peut néanmoins proposer au répondant qui est très intéressé par le projet de fournir un contact pour être informé de l’avancement du projet ou même pour rejoindre le comité des utilisateurs. Un exemple de question d’enquête est montré dans la figure suivante avec l’analyse faite sur les réponses collectées.

Online survey

Être au couran de l’état de l’art

Un état de l’art est généralement déjà disponible dans le cadre de l’élaboration de la proposition de projet. Cependant, un tel état de l’art doit généralement être affiné afin de mieux le consolider, de faire face à l’évolution possible depuis la rédaction de la proposition et surtout de s’adapter à l’apport plus concret fourni par la phase d’analyse des besoins. Dans notre cas, il était important d’avoir une vision claire à la fois des outils de gestion de projet existants et des outils de gestion des risques. Des critères spécifiques ont été identifiés avec les PME comme le coût, les problèmes d’utilisabilité de l’intégration. Parmi les PME concernées, il existe des éditeurs de logiciels et naturellement leurs outils sont pris en compte dans cette mise à jour. Par exemple, la figure ci-après montre la table d’évaluation résultante pour les principales exigences non fonctionnelles identifiées à la suite de la phase des exigences et une courte liste des outils existants également validés par les partenaires en tant qu’outils cibles possibles.

Non-functional requirements for tool selection.

Construire une vision commune

Afin de construire une vision commune qui conduira le projet vers une solution, différents moyens peuvent être utilisés. En plus des bonnes infrastructures collaboratives comme Redmine, nous mettons en évidence deux moyens intéressants avec les notations associées : construire un (méta) modèle du concept (couvrant à la fois les problèmes et les solutions) et définir une architecture de référence de la solution.

D’abord, un méta-modèle est très intéressant à utiliser pour les raisons suivantes :

• il repose sur un ensemble de notations simples qui peuvent aider à partager une compréhension commune d’un domaine entre tous les partenaires de R & D et les PME finales
• l’élaboration d’un méta-modèle à partir de rien peut aussi être un bon exercice, mais à un moment donné, il devrait être confronté à des méta-modèles élaborés par d’autres et publiés dans la littérature. Cela permet de vérifier si le modèle générique est suffisant et dans ce cas il vaut mieux s’en tenir à un travail standard et déjà reconnu plutôt que d’essayer de réinventer la roue.
• le méta-modèle peut être affiné dans de nombreux artefacts d’implémentation tels qu’un schéma de base de données, une API, un modèle de rapport, etc. Il assurera également une cohérence globale et permettra de suivre les évolutions en cas de besoin. La figure suivante montre un méta-modèle simple combinant à la fois les dimensions de projet et les dimensions de risque requises par le projet PRIMa-Q. Il est structuré autour de la notion centrale d’objectif.

PRIMa-Q meta-model.

Deuxièmement, il est important de définir une architecture de référence. Il existe différents objectifs complémentaires derrière la définition d’une telle architecture tels que :

• définir une solution minimale pouvant être prototypée pendant la durée du projet et déployée en collaboration avec certaines PME participantes. Cela signifie que la solution ne devrait pas être trop complexe et devrait se concentrer sur un noyau de fonctions obligatoires. Il devrait également être assez ouvert en particulier avec le type d’interface requis pour réaliser l’intégration requise dans le projet afin de valider le concept sur un cas d’utilisation de l’entreprise.
• construire une solution simple qui peut mettre en évidence l’approche proposée et qui est facile à essayer et à adopter. Cela signifie que la solution proposée ne doit pas être trop complexe et s’appuyer sur la technologie disponible gratuitement (même de préférence Open Source). De plus, la solution devrait s’appuyer sur un composant suffisamment mature pour être convaincant en termes de convivialité et de performance.
• définir une solution suffisamment générique avec un bon potentiel d’exploitation, c’est-à-dire que la solution devrait pouvoir évoluer au-delà de la fin du projet ou s’intégrer dans un environnement plus complexe, y compris les solutions commerciales possibles utilisées sur le terrain. Encore une fois cela appelle une architecture assez ouverte.

Conclusions

Répondre avec succès aux besoins des PME dans le cadre d’un projet de R&D de deux ans est assez difficile. Nous espérons que les lignes directrices présentée ici seront utiles pour guider d’autres personnes à atteindre des objectifs similaires et encourageront également les PME à s’engager dans des projets du programme CORNET ou d’autres programmes de R&D axés sur les PME comme CWALITY. N’hésitez pas à nous contacter pour plus d’informations.