Une approche pour le développement des "petits" projets scientifiques (part. 2)

Au sommaire :

• Introduction ; les différentes approches
• Entre les approches pour entreprise et les projets de recherche
• L'approche la plus adéquate pour les projets de recherche
• Un peu plus loin : un peu de biologie
• Exemple et conclusion

Nous avons terminé la première partie par poser une question très importante : comment choisir le meilleur processus pour un sujet de recherche.
Un sujet de recherche vise, principalement, à vérifier une proposition. Cette dernière est faite après une longue étude théorique, analyse des faits, comparaison, inspiration et adaptation des techniques existantes. Elle peut être très simple ou très complexe, mais, nous pouvons affirmer ce qui suit :

1. Un seul besoin :

Une proposition peut être exprimée comme un seul besoin. Cela ne veut pas dire que l'application doit forcément être de petite taille.
Un seul besoin comme : "l'analyse des traces émotionnelles dans un texte libre" peut être représenté par un seul cas d'utilisation doté d'une interface graphique très simple (une seule fenêtre ou page web qui offre une zone de saisie, un bouton pour lancer le traitement et une zone pour afficher le résultat du traitement), mais, les traitements nécessaires pour réaliser ce traitement peuvent être liés à la Recherche d'information (découpage, nettoyage, pondération, repérage des mots clés émotionnels), au web sémantique (détection des concepts, désambiguïsation, mesure de similarité) ou bien à l'intelligence artificielle (réseaux de neurones).
Un autre besoin comme : "conception et réalisation d'une plate-forme e-Learning basée sur les services web" peut être traduit par un seul besoin  technique mais sa mise en pratique doit passer par la reprise de toute la conception d'une plate-forme e-Learning avec les différents cas d'utilisation, les différentes possibilités d'interface graphique et le résultat est une application relativement complexe. Nous signalons, ici, que le (jeune) chercheur n'est pas obligé de proposer une nouvelle vision et des nouveaux cas d'utilisation pour la plate-forme e-Learning; il peut, d'ailleurs, reprendre une conception existante tout en respectant les droits d'auteur. Il y aura certainement des adaptations et des modifications mais pas une conception "from scratch".

2. Le besoin ne change pas :

Un changement du besoin ne peut être envisagé que si le sujet de recherche lui même a changé. Cela ne provoque pas une modification de l'application mais une annulation de cette dernière. Il faut faire la différence entre un changement dans l'environnement de l'entreprise et un changement de la thématique de recherche : le premier provoque, rarement, un changement radical dans l'entreprise; et même s'il le fait, l'option de reprendre le développement de son système d'information à zéro est toujours envisageable. Le deuxième provoque, généralement, un changement radical parce que il s'agit d'un changement de concept ou de notion traitée ce qui va se répercuter sur toute l'étude théorique ainsi que son implémentation.

3. Pas de séparation entre les besoins techniques et fonctionnels :

Il s'agit d'un seul besoin qui est le besoin principal qui découle directement de l'hypothèse à prouver. Ainsi, la présentation de l'étude théorique et de la partie proposition doit se focaliser sur ce besoin; les autres éléments ne doivent être présentés que dans le mesure du nécessaire.
Reprenons notre exemple sur "le développement d'une plate-forme basée sur les services web". Il est possible d'envisager un processus en cascade ou autre, mais, il sera très dommage si nous ne voyons les services web que pendant les 20 dernières pages (c'est à dire la partie réalisation) sur un la partie conception qui occupe 60 pages ou plus avec toutes ses étapes.

4. Plusieurs itérations ? Difficile à imaginer :

La stabilité de (ou même des besoins si on regroupent tous les éléments de l'application) ainsi que l'absence d'un ensemble de notions supposées être primordiales pour l'entreprise telles que :

1. Le temps de livraison (délai) : le délai de livraison est un élément essentiel du contrat informatique, néanmoins, cette notion n'a pas cette importance particulière dans un cadre de recherche. Le plus important est le respect de la proposition effectuée et la réalisation des testes suffisants pour prouver l'efficacité (ou pas) de la solution proposée pour déduire par la suite est ce que l'hypothèse effectuée est varie ou pas.
2. La phase de transition : cette phase est utilisée dans un cadre professionnel pour permettre aux employés de passer progressivement de l'ancien système vers le nouveau système (il est même possible d'envisager une utilisation simultanée des deux systèmes au même temps). Cette phase permet de collecter de nouveaux critiques comme elle représente une occasion idéale pour raffiner et compléter la formation offerte aux employés. Dans un cadre de recherche, l'absence de la notion de production engendre l'absence de la notion de la phase transitoire, ainsi, les utilisateurs sont directement accompagnée par le développeur ou le chercheur pour mener à bien les expérimentations nécessaires sur le système.
3. La formation des utilisateurs : l'accompagnement des utilisateurs par les membres de l'équipe de recherche est suffisant vu que les données sont collectées à des fins d'expérimentation; faire des erreurs est significatif (l'IHM est inefficace, le système est trop complexe, ces données sont à ignorer - tout simplement, etc.) comme il n'y a pas un risque réel de perte, destruction du système, "arrêt de la production". Ainsi, envisager une formation à part pour les utilisateurs est un investissement coûteux et non justifié.
4. Les points de contrôle : dans un processus itératif ou même simple, le passage d'une étape à l'autre nécessite une validation de la part du sommet stratégique. Cela se fait par le positionnement de plusieurs points de contrôle tout au long du cycle de développement. Ces points de contrôle se concrétisent par des réunions de validation qui permettent de valider un modèle, de tirer de nouveaux besoins, d'obtenir de nouveaux critique et, le plus important, garder le projet dans la bonne direction. Toutes ces notions ne trouvent aucune projection dans le monde de recherche sauf dans le cadre du laboratoire : travailler sur une nouvelle proposition veut dire l'absence de tout point de référence pour juger la bonne conduite ou pas du sujet; une telle décision ne peut être prise qu'après l'obtention des résultats des différentes expérimentations.

Il est évident que les remarques ci-dessus concernent des cas généraux des projets de recherche en informatique. Ces remarques ne sont, probablement, pas vraies pur d'autres domaines comme elle ne le sont pas pour certains types de projets financé par des budgets particulièrement grands (certainement pas une seule thèse de doctorat ou bien un seul projet de fin d'étude).
En prenant en compte ces caractéristiques, pouvons nous répondre à la question posée précédemment ?

(Pour plus d'informations sur l'auteur et le blog, c'est par ici)