Téléchargez la version PDF
Le projet comme notion
Extrêmement répandu dans la recherche, il est important de retenir qu'un projet est inscrit dans un contexte, qu'il est unique, mais aussi temporaire. De plus, il est constitué de ressources identifiées qui sont nécessaires à son élaboration.
Définition AFNOR : « Le projet est un processus unique qui consiste en un ensemble d'activités coordonnées et maîtrisées, comportant des dates de début et de fin, entrepris dans le but d'atteindre un objectif conforme à des exigences spécifiques, incluant des contraintes de délais, de coûts et de ressources. »
Le projet intègre donc un ensemble de variables qu'il faut prendre en compte dès le début de sa réflexion :
> Un objectif à atteindre
> Un domaine
> Un délai
> Des moyens (matériels, financiers, humains)
> Des contraintes
> Des résultats
Le projet comme lieu de rencontre
Le projet met en place un dialogue entre plusieurs acteurs qu'ils soient humains ou matériels. Ce dialogue doit pouvoir rester continu tout au long du déroulement du projet.
La structuration préalable comme point de départ
> Faire un inventaire des ressources humaines :
• internes à l’organisme dans lequel on évolue,
• mais aussi externes.
Les chercheurs sont ancrés dans une communauté dans laquelle ils peuvent trouver des supports pour le projet. Cependant il faut, dans un premier temps, évaluer cette communauté : qui peut faire quoi ? Les acteurs sont-ils proches/loin/accessibles ?
> Considérer le réseau qui peut déjà exister autour du projet (Base de données, association…)
> Effectuer un état de l’art sur ce qui a déjà été réalisé, ce qui pourrait être réalisé, ce qui existe et ce qui n’existe plus, acquérir le vocabulaire spécifique… (trouver des projets similaires non seulement ceux qui ont fonctionné, mais également ceux qui ont échoué, se renseigner sur les techniques auprès d’un ingénieur par exemple…)
Il s’agit là d’une étape essentielle pour Richard Walter, la majorité des ingénieurs refusant catégoriquement de travailler avec un chercheur qui n’a pas accompli ce travail préalable.
Un des participants soulève alors une question essentielle : comment l’ingénieur peut-il savoir que le chercheur qui vient lui présenter son projet n’a justement pas étudié cet état de l’art ?
Pour Richard Walter, la réponse est simple : en tant que professionnel des questions de technicité, un ingénieur détecte de suite un chercheur qui n’est pas à la page techniquement. Celui-ci lui propose par exemple des solutions désuètes voire qui n’existent plus.
L’équipe projet comme équipe de film
Le projet évolue dans un espace-temps donné dans lequel gravitent des compétences différentes au même titre qu’un film dont la collaboration et la diversité des acteurs ne sont pas sans rappeler celles des protagonistes d’un projet. Selon Stéphane Loret et Richard Walter, le montage d’un projet peut ainsi se rapprocher à celui d’un film :
> Le chercheur en est le scénariste
> Le professionnel de l’information chargé de son traitement assure le Story-board et la prise de vue
> L’informaticien fait le montage.
> L’infographiste s’occupe de la lumière et des décors
> Et le webmaster fait figure de projectionniste
Après avoir délimité les contours et les contextes évoluant autour du projet, il faut donc ensuite délimiter les fonctions de chacun et opérer un casting. Il s’agit ici d’opter pour les équipes scientifiques et les partenaires techniques.
Quelques acteurs principaux comme fonctions-clés
Le MOA (Maîtrise d’ouvrage)
Il est l’entité porteuse du projet et représente donc à juste titre le commanditaire, le client pour qui l’ouvrage est conçu. Il lui incombe de définir les objectifs à atteindre et les délais à suivre et de maintenir le cadre de développement du projet.
Le MOE (Maîtrise d’oeuvre)
Il est le responsable des choix techniques. Il identifie, planifie et réalise les travaux techniques et choisis les ressources qu’il utilisera pour cela (matérielles, mais aussi humaines). Il apporte également des solutions et ses compétences aux problèmes ou aux faiblesses techniques du projet. En effet, il s’agit ici de lier un dialogue. Le chercheur ne doit en aucun cas tout entreprendre seul et le MOE est aussi là pour l’accompagner. De même, il rend une prestation au chercheur et il doit donc lui rendre compte de son travail.
Le chef de projet
C’est un poste permanent qui va devoir gérer plusieurs corps de métier différents. Il s’agira de déterminer non seulement un chef de projet-chercheur, mais aussi un chef de projet-ingénieur. C’est lui qui insuffle l’énergie et de vitalité pour le projet.
Comités et conseils
Il s’agit ici de constituer des organes destinés au Peer-review[1] des actions des uns par les autres. Richard Walter a tenu à souligner ici qu’il est important de ne pas effectuer de dichotomie chercheur/ingénieur, mais d’associer les deux entités dans ces groupes de travail.
> Le comité de pilotage suit l’avancement des travaux et prononce un arbitrage des différents acteurs du projet. Il réunit les deux chefs de projet : le chef de projet-chercheur et le chef de projet-ingénieur et doit se réunir de manière soutenue à chaque étape-clé (3/4 réunions environ).
> Le comité de suivi est l’organe exécutif du projet. Il conduit l’application des décisions du comité de pilotage (le respect des délais…)
Dans cette partie dédiée à la présentation de l’équipe-projet, les intervenants ont tenu à rappeler à de nombreuses reprises que pour l’élaboration d’un projet, l’isolement est banni. Il faut continuellement être dans une logique de dialogue. L’essentiel est de communiquer, de rendre compte de ce que l’on fait, de ce que l’on attend, de ce que l’on pense… pour pouvoir avancer.
De plus, ils ont également souligné le fait que le schéma d’une l’équipe en situation réelle était bien souvent moins utopiste, car les acteurs n’ont pas toujours l’occasion de se rencontrer, les délais doivent parfois être revus… Un projet n’est pas figé !
Il ne faut pas non plus l’oublier pour la modélisation du Workflow[2] qui ne doit pas être envisagé comme quelque chose de linéaire : il faut pouvoir s’adapter à tout moment selon les contraintes ou possibilités qui s’offrent à soi.
Le projet comme méthodes de travail
On ne se lance pas dans un projet sans avoir d’abord déterminé dans quelle direction l’on veut aller et la façon dont on va fonctionner pour pouvoir atteindre son objectif. Dans cette partie, les deux ingénieurs présentent quelques pistes de travail ainsi que diverses manières d’envisager la conception d’un projet.
Le projet comme un Retour vers le futur[3]
Pour nos deux ingénieurs, travailler « en mode projet » revient pour le chercheur et son équipe à se glisser dans la peau des deux protagonistes de la série des films à succès Retour vers le futur, le docteur Emmett Brown et Marty McFly. En effet, ici, les finalités du projet sont déjà connues et c’est même à partir d’elles que le projet est pensé, voire envisagé ; un certain laps de temps sera cependant nécessaire pour les atteindre.
Mais est-il vraiment possible de connaître à l’avance le retour de l’expérience ?
Le projet comme « Mille-feuille »
Une intervention de la part d’un participant sur le caractère durable d’un projet a donné prétexte à Richard Loret pour évoquer la technique du « mille-feuille » dans le montage d’un projet. En effet, comme l’a très bien souligné le participant en question, il est nécessaire d’envisager le projet dans le long terme et d’ainsi considérer l’après : continuer à faire vivre la base, la faire évoluer, l’alimenter… Mais les budgets alloués par tranches de trois années généralement ne suivent pas vraiment cette logique et afin de pouvoir conserver un financement dans la durée, existe la méthode dite du « mille-feuille ». Il s’agira de découper le projet en plusieurs parties et d’acquérir un budget de trois ans pour chacune d’entre elles successivement. Le but étant de ne pas tout dire sur le projet dans chaque demande de budget afin de pouvoir ensuite faire foi d’une progression, d’une nouveauté.
Cette intervention a également permis de discuter de la problématique de la pérennité du projet. Il faut dès le début penser aux questions d’hébergement du projet (pourra-t-il être archivé à long terme ?), de pérennité des formats (préconiser des formats qui ne risquent pas de disparaître dans peu de temps), etc.
Le projet comme « ouverture vers l’extérieur »
Le projet n’est pas l’affaire d’une personne, d’une discipline ou d’une technique, mais forme un écosystème unique thématique, disciplinaire, sectoriel, local (le laboratoire de recherche) et global (à l’international) où tout se mélange : informaticiens, chercheurs ou encore grand public se retrouvent bien souvent réunis dans les projets et le numérique apporte aujourd’hui de nombreuses solutions à la mise en interaction.
Le Crowdsourcing[4]
Il permet d’élargir la participation au projet au-delà des membres de l’équipe à proprement parler, notamment pour la collecte effective des contenus. Ce modèle se développe principalement pour les projets à destination du grand public ou qui se destinent à des questions de société. Pour l’illustrer, Richard Walter a donné l’exemple de bases médicales spécialisées dans les maladies orphelines. La méconnaissance de ces maladies par les chercheurs eux-mêmes font parfois des patients les personnes les plus à même à en discuter.
Mais Richard Walter n’oublie pas de rappeler que la mise en place d’une interactivité extérieure à celle de l’équipe-projet est difficile et qu’elle réinterroge de nombreux aspects du projet. Cette participation externe nécessite, en effet, d’être modérée et contrôlée, notamment par une instance scientifique du projet. On se situe ici dans le terrain de la recherche et la légitimité des propos véhiculés par le projet est d’une extrême importance.
Richard Walter explique notamment que si l’on veut construire une page Wikipédia du projet, pour que celle-ci soit faîte correctement il vaut mieux la créer soi-même pour pouvoir la modérer ensuite. Il en est de même avec un site officiel ou une page de réseau social. Toutefois, il faut être prudent, « tous les projets ne nécessitent pas un site officiel, un Facebook ou un Twitter. » (Richard Walter). Tous les projets n’ont pas les mêmes besoins et certains ne nécessitent donc pas de collaborations vers l’extérieure.
La sécurité des données
De même, l’ouverture à l’extérieure, et notamment la diffusion du projet sur internet, réinterroge le problème de la sécurité des données émises. En effet, si la propriété des données est normalement détenue par le chercheur, leur édition à grande échelle et sur un média tel qu’internet met en jeu des questions telles que le pillage des données. C’est pourquoi les deux intervenants ont rappelé que la traçabilité des informations doit être au cœur des problématiques liées au projet. Il faut mettre dès le début une véritable politique et méthodologie de traçage des données comme le renseignement des métadonnées, l’envoie par mail d’une confirmation de dépôt dans la base, etc.
Cependant, Stéphane Loret a tenu à souligner qu’il ne fallait pas craindre la diffusion sur internet, mais au contraire s’en acquitter au plus vite et en premier, car plus large est la diffusion, moins grand sera le risque de se faire piller. Mettre en ligne c’est être visible, c’est montrer que nous sommes les producteurs des données diffusées. Ces éléments de méthodes permettent pour certaines de se mettre en immersion dans le projet, pour d’autres de proposer des éléments et des questions auxquels il est impératif de répondre dans la phase de préparation du projet.
L’entité porteuse du projet doit convaincre un ensemble de personnes différentes (ingénieurs, grand public, politiques…) non seulement sur l’intérêt scientifique de son projet (que va-t-il apporté à la recherche ?…), mais également sur sa légitimité (qui peut être portée par exemple par un Peer-review assuré par un comité scientifique).
Le projet comme processus
Le déroulement du projet se poursuit sur plusieurs phases, mais avant d’entrer dans le projet, quelques éléments sont à envisager et à intégrer par le chercheur.
Le projet comme principes
> Se forger une culture numérique notamment pour pouvoir entrer en dialogue avec l’ingénieur et argumenter.
> Avoir l’exigence de la collaboration.
> Évoluer dans une structure multiscalaire. Au niveau local, de l’infrastructure et des communautés. S’ouvrir au-delà de sa propre discipline et s’interroger sur ce qui peut être mobilisé.
> Penser unicité et innovation, même si le projet s’inspire de quelque chose qui a déjà été fait, il reste singulier.
> La donnée est fondamentale et elle doit être pérenne. Il faut pouvoir gérer l’ensemble de son cycle de vie. Pour illustrer le cas d’une donnée perdue et mal usitée, Richard Walter a donné l’exemple d’une base de données des œuvres de Flaubert dont le formulaire était tellement long, qu’il éparpillait les données et que l’on ne savait plus exactement où celles-ci se trouvaient. Il ne faut pas essayer de faire trop précis sous peine de faire trop complexe.
> Le projet est un contenu : gestion, structuration et exposition de données ou le projet est un Framework : traitement du contenu (logiciels de traitement linguistique, sonore…)
Il faut se questionner non seulement sur la communication et la visibilité du projet, mais aussi sur la publication et le stockage des données ainsi que sur le développement informatique et technique.
Le projet comme pilotage : Y a-t-il un pilote dans l’avion ?
Il s’agit ici de mettre en place la démarche à assurer pour le projet (planning, réunion, organisation, livrables…). Le chercheur doit savoir prendre de la distance avec son projet pour avoir un regard externe et neutre. Mais attention, Stéphane Loret prévient : « Parfois, le chercheur a tellement pris de distance avec son projet, qu’il n’est plus là et le projet ne peut donc plus avancer, car c’est lui qui le pilote. »
> Inventaire des besoins : pour qui ? Pour quoi ? Sur quoi influent-ils ?
> Inventaire des compétences et des moyens : qui fait quoi ? Quand ? Où ? Pour qui ? Comment ? Pour combien ? Pourquoi ?
> Trois axes de pilotage :
• Se poser les bonnes questions pour organiser de manière rationnelle les activités dans un laps de temps imparti.
• Coordonner des acteurs et des tâches en vue de l’efficacité et de la rentabilité. Il faut aussi pouvoir animer une équipe qui n’est pas constituée que de personnes connues.
• Définir les objectifs scientifiques et cadrer les limites du projet.
> Trois conseils de pilotage :
• Garder une trace de la préparation du projet et de son évolution en vue du bilan à réaliser à la fin. « Il faut capitaliser pour la suite » selon Stéphane Loret.
• Survivre en gérant les imprévus notamment, car le plan de départ ne colle jamais à la réalité, mais sert de guide qui sera changé au cours de l’avancée du projet.
• Être pragmatique avec un principe de réalité, laisser des marges et des délais réalistes et établir des évaluations intermédiaires à chaque étape.
Le projet comme succession de phases
La phase préparatoire
Elle consiste dans un premier temps à réaliser une note de cadrage qui détermine les contextes (partenaires…), les ressources et les enjeux du projet.
Il s’agit également ici d’entreprendre une étude de faisabilité notamment au niveau organisationnel, économique, technique ou encore scientifique et d’analyser les besoins.
Cette phase comporte enfin la création d’une étude détaillée matérialisée par le cahier des charges fonctionnel qui fera l’inventaire des besoins et des résultats attendus. Mais également la création du cahier des clauses techniques particulières qui déterminera les solutions techniques choisies pour la réalisation du projet.
La phase de réalisation
Il s’agira dans un premier temps de réaliser le projet en découpant celui-ci en activités de tâches (Work-packages) qui seront planifiées ensuite de manière prévisionnelle. Cette phase comprendra la mise en place d’un tableau de bord, du Reporting[5] du projet et enfin d’un référentiel du produit, réunissant tous les livrables.
Dans un second temps, il s’agira de valider le projet en évaluant si celui-ci répond correctement au cahier des charges en effectuant des tests. Richard Walter a rappelé qu’il était d’ailleurs important de ne pas oublier de prévoir une étape de « débogage », autrement dit corriger les erreurs de programmation, dans le planning prévisionnel au cas où les résultats ne seraient pas concluants lors des phases de test.
La phase de déploiement
C’est la phase de mise en production du projet, de maintenance de celui-ci et de capitalisation des savoirs au travers de la constitution d’un bilan. Stéphane Loret tient à préciser que la création d’un document de transfert de compétences techniques peut aussi être d’une utilité indispensable. En effet, le projet peut perdurer, mais les acteurs peuvent changer et les nouveaux arrivants doivent pouvoir prendre la suite en toute connaissance de cause et de manière efficace immédiatement.
Le projet comme conclusion
Il faut porter un temps et une attention particulière à la phase de préparation, car c’est à partir de cette étape initiale que se joue le succès d’un projet puisqu’il s’agit de sa mise en place intégrale.
De plus il ne faut pas hésiter à créer des documents tout au long de la conception du projet afin de garder une trace de tout ce qui a été fait, les documents sont des outils utiles du début à la fin.
Enfin, il faut dédramatiser les relations chercheurs/ingénieurs et oublier ses préjugés comme l’un comme pour l’autre.
[1] Le Peer-review désigne l’évaluation et la validation d’un travail par une personne ou plus détenant des compétences similaires aux producteurs de ce travail, on le traduit aussi par « évaluation par les pairs »)
[2] Le workflow sert à décrire l’ensemble des tâches à répartir entre les différents acteurs du projet, les délais, les modes de validation, et à fournir à chacun des acteurs les informations nécessaires à l'exécution de sa tâche
[3] Zemeckis Robert, Back to the Future, 3 juillet 1985.
[4] Méthode de travail en collaboration ouverte.
[5] Le Reporting d’un projet permet de communiquer sur son état d’avancement et les questions à traiter.
Auteur : Camille Bajeux
DHnord2014. Humanités numériques : des outils, des méthodes, une culture.
Retrouvez d'autres contenus sur le site du colloque : http://dhnord2014.meshs.fr
Stéphane Loret et Richard Walter ont proposé, lors de ce premier atelier consacré au montage d’un projet, d’aborder les différents éléments à prendre en compte et les différentes questions à se poser en vue de la réalisation d’un projet. Ils ont apporté quelques réponses préalables sans toutefois les présenter comme le seul modèle à suivre.
Camille Bajeux est étudiante en Master 1 en sciences de l'information et du document à l'université Lille 3. Elle effectue son stage de fin d'année au sein de la MESHS, en tant que chargée de la documentation et de la restitution du colloque DHnord2014. À ce titre, elle a participé aux deux sessions de l'atelier "Réaliser un projet humanités numérique" pour lesquels il a rédigé des comptes rendus.
Organisation : Maison européenne des sciences de l'homme et de la société, Learning Center Archéologie/Égyptologie/SHS de l'université Lille 3
Partenaires : Conseil régional du Nord-Pas-de-Calais, Open Edition, GERiiCO, Ecole doctorale SHS, Ecole doctorale SJPG, ANR CHispa
› CDRH, « Best Practices | Recommendations for Digital Humanities Projects », Portail, CDRH : Center for Digital Research in the Humanities / University of Nebraska-Lincoln, 7 avril 2014. Consulté le 7 mai 2014. <http://cdrh.unl.edu/articles/best_practices.php>
› « Quelles compétences et littératies pour les humanités numériques ? », in Non-actes de la non-conférence des humanités numériques, présenté à THATCamp Paris 2012, Paris, Éditions de la Maison des sciences de l’homme, 2012 (La Non-Collection), p. 45-49. ISBN : 9782735115273. Consulté le 13 mai 2014. <http://books.openedition.org/editionsmsh/334>
› Dousset Laurent, Minel Jean-Luc, Pouyllau Stéphane et Walter Richard, Le guide des Bonnes Pratiques Numériques, TGE-Adonis, décembre 2009. Consulté le 21 mai 2014. <http://www.aedres.fr/pdf/Bonnes_Pratiques_numerique.pdf>
› UCLA Center for Digital Humanities, « Introduction to Digital Humanties | Concepts, Methods, and Tutorials for Students and Instructors », Portail, Intro to Digital Humanities, [s.d.]. Consulté le 7 mai 2014. <http://dh101.humanities.ucla.edu/>
› Warwick Claire, Galina Isabel, Rimmer Jon, Terras Melissa, Blandford Ann, Gow Jeremy et Buchanan George, « Documentation and the users of digital resources in the humanities », Journal of Documentation, vol. 65, no 1, 16 janvier 2009, p. 33-57.
URI/Permalink: