La notion de cadre, dans les projets numériques et dans toute co-élaboration

Qu’est ce que le cadre en gestion de projet fonctionnelle ? Quelques réflexions à partir de l’exemple des projets numériques et collaboratifs, afin de questionner, de développer un regard « méta » sur nos cadres, la façon de les poser, et ce qu’ils impliquent.

Partons de l’idée du cadre « légal » ou « social » – notion d’implicite et d’explicite

Comme point de départ par lequel tout le monde peut se sentir concerné, on peut comprendre le mot « cadre » dans le sens donné par ce qui décrit, en termes légaux, la gouvernence d’une organisation : le cadre d’interaction, les règles et structures qui régissent les échanges. Exemple : examinons les attributions juridiques d’une association : statuts, dirigeants, bureau éventuel,… Elles régissent ce qui doit se passer, notamment le fait que des dirigeants soient nommés parmi les membres (constituant tous ensemble l’assemblée générale), et qu’un objet social sans but lucratif est énoncé pour décrire les actions menées. Idem pour toute autre forme juridique : on parle du cadre légal. L’organisation peut bien entendu se doter d’autres cadres et d’autres règles, extra-légales, explicites.

Ces cadres d’interaction sont (ou en tous cas se veulent) explicites, d’autres sont plus implicites. Par exemple, dans la rue, quand on croise quelqu’un qu’on ne connaît pas, on s’arrange pour ne pas le coller. On laisse à la personne un « périmètre de tranquilité », même si ce ne serait pas illégal de lui mettre une main sur l’épaule sans qu’il ne demande rien.

Notion de cadrage projet

Comment cette notion de cadre peut-elle être mise en œuvre dans la gestion de projet, notamment fonctionnelle ? Il y a tout d’abord le cadrage du projet. Cette phase, qui permet de cerner le besoin, les moyens, les enjeux, est souvent mésestimée, pourtant la mener à bien conditionne largement la réussite du projet. Cadrer un projet, c’est préciser dans quel cadre on doit agir c’est-à-dire définir les limites, les contraintes du projet. On définit cela en terme de temps, de budget et plus généralement de moyens, de degré de satisfaction des besoins. Comme pour le cadrage d’une photo, cela permet de mieux spécifier en particulier ce qui relève ou non du projet, le « périmètre ». Et là aussi, il y a des limites implicites qu’il peut être profitable d’expliciter. Je pose ces notions, sans toutefois entrer dans l’exposé de la méthodologie du cadrage projet, connue et bien décrite sur plusieurs supports. 

Du cadre méthodologique du projet au cadre des interactions entre les acteurs : comparaison cycle en V / méthode agile

 Ce cadrage du projet nécessite aussi un cadrage des interactions dans le projet : préciser qui mène le projet, qui va œuvrer au projet, avec quel rôle, quitte à ce que cette structuration de l’équipe puisse évoluer selon les besoins. Ensuite, il est utile de cadrer la méthode qui sera utilisée, c’est-à-dire décider puis expliciter les processus, voire même les outils, qui vont être employés. La méthode peut influer sur les rôles. En effet, si en méthode scrum on a le scrum master, le product owner, et les équipiers, et en cycle en V on a un chef d’équipe, pour l’équipe de maîtrise d’oeuvre, avec dans l’équipe plusieurs rôles (analyste, développeur, testeur), et une assistance à maîtrise d’ouvrage, ces personnes pouvant être organisées en comité de projet (copro) et comité de pilotage (copil),… avec évidemment toutes les organisations intermédiaires possibles.

La méthode définit le « style » de cadre, puisque si avec le cycle en V on a un cadre plutôt fixe, défini par le cahier des charges, en méthode agile on affine le cadre au fur et à mesure, de façon itérative : il y a une notion de souplesse, d’adaptabilité. Le propos n’est pas de dire si l’un est meilleur que l’autre : en effet, quand on définit des infrastructures, ou des développements structurants (constitution d’une base de données SQL, base technique d’un système d’informations,…) on est contraint à une certaine fixité, moins nécessaire si on est en web-only, ou sur la partie front d’un applicatif.

Cadre méthodologique et principe de réalité

On retrouve également dans la comparaison entre ces deux méthodes la notion de cadre d’interaction, au sein de l’équipe projet. En fait, cela relève du même « principe de réalité » que le cadrage projet général, car au sein du projet mis en place, il y a un sous-projet de coopération entre les individus. Celui-ci doit prendre en compte la réalité « physique » des différents acteurs : besoins (cf pyramide de Maslow), temps limité, savoir, savoir-faire et savoir-être de chacun. Là encore, beaucoup d’implicite : nous n’avons que deux oreilles et un cerveau : pour la plupart d’entre nous, un seul flux d’information suffit. De fait, les réunions où deux sous-groupes se constituent sans que le processus ne l’ait prévu, ne servent pas le principe même de réunion qui est d’être ensemble.

Autre « règle » à se donner, on ne peut pas imaginer, quand le groupe fait plus de 10 personnes, que les membres puissent être tous en position de coopération active. Certains vont forcément se désengager, devenir plus passifs, voire penser à autre chose, ce qui à nouveau ne sert pas le processus. Il faut alors une méthodologie claire, un cadre « serré » qui permette à chacun d’exprimer a minima une vraie approbation ou une vraie objection, pour interagir. Evidemment, on ne va pas utiliser une telle grande assemblée pour faire avancer un projet. Ainsi on prête à Jeff Bezos une règle selon laquelle un équipe projet doit être dimensionnée pour être nourrie par 2 pizzas ! Ce n’est pas simplement pour l’aspect logistique des déjeûners de travail.

Expliciter, concevoir, ajuster le cadre, nécessite d’abord des compétences d’analyse. Il n’est permis que si un recul est pris avant l’action. Il va permettre d’avoir une meilleure visibilité du but et des moyens à disposition pour l’atteindre. C’est donc décisif pour la réussite du projet, et malheureusement souvent négligé.

Cadres relationnels dans tout projet de co-élaboration

Au même titre que le développement informatique a fait évoluer la gestion de projet en général, on peut s’inspirer des réflexions autour du cadrage, de l’organisation de l’équipe, pour toutes sortes de projets, voire de situations. L’ambition même d’envisager une collaboration – une co-élaboration plus précisément – c’est-à-dire de travailler en intelligence collective sur un projet, un sujet, une problématique, est, comme mentionné plus haut pour les projets numériques, un projet en soi, un projet « dans le projet ».

Dans les milieux « alternatifs », de travail psychologique ou de vie spirituelle, les modalités de prise de parole sont souvent « cadrées », explicitées. Souvent on invite à ne pas couper la parole des personnes, voire attendre que la personne spécifie qu’elle a fini de parler. C’est potentiellement très contraignant ! Imaginons ce qui peut arriver si quelqu’un a vraiment besoin de racontrer sa vie… On peut en avoir pour l’après-midi ! J’observe que cela ne se passe jamais, sans doute que le cadre implicite de ce genre de rencontres est qu’il y ait une répartition équitable de la parole. Le cadre (posé par le facilitateur) précise si la parole est « tournante », « au centre » ou en pop-corn (sans règle précisée), ou autre règle (chacun peut désigner une autre personne après son intervention) ; si tout le monde doit s’exprimer ou non ; si quelqu’un en particulier doit parler en dernier (quelqu’un dont on doit receuillir l’approbation, par exemple si elle est désignée en élection sans candidat).

Certains disent : « c’est lourdingue ! » ou « est-ce bien nécessaire ? » A cela je réponds catégoriquement : parfois, oui ! Parfois, les conditions de sécurités relationnelles ne sont pas remplies pour qu’une discussion libre et non cadrée (ou avec un cadre implicite lâche) soit vraiment fructueuse, et permette un niveau d’engagement de chacun correct. On a tous vécu cela : une réunion où on n’a pas l’impression d’avoir avancé, où l’ambiance était violente, sans qu’on puisse vraiment dire ce qui n’allait pas. De plus, il ne faut pas avoir trop peur du temps passé. Ces pratiques sont une gymnastique à laquelle on s’habitue vite, qui une fois maîtrisée, peut être aussi voire plus rapide qu’une discussion classique.

Exemples de cadres de co-élaboration

En plus de ces règles d’intervention, cadres ponctuels ajustés de façon dynamique à chaque sujet traité, chaque moment de la discussion, le ou les organisateurs peuvent avoir énoncé un cadre général (« cadre de sécurité », « cadre d’engagement commun », « charte »,…) dont je vais donner deux exemples, par des organisations spécialisées dans le « faire-ensemble » :
– celui de l’Université du Nous. Un peu variable (car évolutif, et fonction des groupes) mais généralement basé sur « confidentialité », « bienveillance », « souveraineté », il est opposable, chacun en est garant.

 – celui d’InsTerCoop. « Il n’y a pas de bonne ou de mauvaise réponse. Toute réponse ou non réponse est valable »

Cela m’invite évidemment à la comparaison. On a d’un côté un cadre assez explicite – bien que les mots employés puissent apparaître flous. On contaste que certaines personnes (qui se pensent violentes, pensent ne pas savoir garder des secrets, ou n’assume pas leur légitimité à prendre la parole) pourraient vivre ce cadre en étant frustrées et inhibées dans leur comportement. L’intérêt du cadre est de préciser l’intention que le groupe souhaite avoir. De l’autre un cadre potentiellement lâche, sans aucune pression dans aucun sens, semble posé. Les mots sont très précis, mais on entend souvent quand on entend ce cadre « on peut tout dire ». Force est de constater qu’il y a une vrai différence entre ce qui est dit et ce qui est entendu.

Notons également que la personne qui pose le cadre est déjà en assymétrie, en posture haute, en rapport de prescription, puisqu’elle a la légitimité de poser le cadre. Le groupe remet et reconnaît alors à ce cadre une autorité, celle de réguler temporairement la liberté des individus.

Notion de temps, et conclusion

Enfin, il me faut introduire le paramètre temps.

Qu’est-ce qui peut faire opter pour un cadre plus ou moins serré, plus ou moins contraint ? Le temps, et le rapport objectifs attendus/temps. En effet, c’est bien ce qui nécessite qu’un chef d’orchestre soit désigné pour la réalisation d’oeuvres musicales : cela se fait en instantané, et on ne peut plus, au moment de jouer, décider de comment régler l’intensité des cuivres, la longueur de ce ritendo. Pilotée par une personne, cette expression en musique prend sens et l’orchestre n’est plus alors qu’un merveilleux organe au service de ce chef avec qui il fait corps. Cela n’empêche absolument pas discussions et débats lors des répétitions. Cependant, dans cet exercice très classique de la réalisation d’une oeuvre musicale pré-écrite, il n’y a aucun but de « créer de l’intelligence collective » sur des plans décisionnels ou de recherche de solution. Ce qui est, comme on l’a vu, un projet en soi, dont il faut accepter qu’il prenne du temps.

 Acceptons donc d’utiliser des cadres d’interaction plus ou moins serrés selon le besoin, les contraintes et notamment la temporalité. Acceptons qu’il n’y ait pas une seule bonne manière de poser un cadre, que la personne en charge peut avoir une manière personnelle de le faire – comme chaque artisan marque de son empreinte ses réalisations – et que ce cadre doit être défini chaque fois selon le contexte. Mais surtout, prenons le temps du recul et de la formalisation de ces cadres – pour qu’ils fassent l’objet d’une acceptation, sans rejet, conscient ou non, de la part des contributeurs – et de la relecture. Prendre le temps d’apprendre à coopérer pour cultiver un « faire ensemble » plus ajusté, efficace et serein.