Vous connaissez déjà le mode d’échec du travail de groupe, parce que vous l’avez vécu : on se répartit les parties en début de projet, chacun fait la sienne dans son coin, et on agrafe le tout la veille du rendu. Le résultat se voit — les quatre morceaux ne se ressemblent pas, deux se contredisent, personne ne sait expliquer la partie du voisin.

Ce n’est pas un défaut de sérieux. Trois de ces quatre personnes ont consciencieusement fait leur travail.

C’est un défaut de structure, et c’est le même dans toutes les techniques qui vont suivre. Aucune ne tient par la bonne volonté des participants ni par la consigne de l’enseignant. Chacune tient par une seule chose :

Est-il possible de faire sa part tout seul ?

Si oui, quelqu’un le fera — pas par mauvaise foi, simplement parce que c’est plus rapide. Et le dispositif se videra sans que personne n’ait décidé de l’abandonner.

graph TD
    Q{Puis-je faire ma part
seul dans mon coin ?} -->|oui| P[Travail parallèle
des solos agrafés]
    Q -->|non| C[Travail collaboratif]
    class P alerte
    class C ok

Passons les techniques en revue par cette question-là. Chacune a une condition, et chacune a la panne qui arrive quand la condition saute.

Le binôme au clavier

Deux personnes, une machine : l’une écrit, l’autre suit, commente, repère. On échange régulièrement les rôles.

La condition : l’alternance réelle, et un écart de niveau modéré.

La panne : l’un tape pendant deux heures, l’autre regarde son téléphone. Ce n’est plus un binôme, c’est une personne qui travaille devant un public. La panne est d’autant plus probable que l’écart de niveau est grand — celui qui va vite prend le clavier « pour aller plus vite », et il a raison à court terme, ce qui rend la dérive difficile à refuser.

Le correctif est mécanique plutôt que moral : un minuteur. On change de main toutes les dix minutes, que ce soit le bon moment ou non. Un dispositif qui dépend de la vigilance de quelqu’un finit toujours par céder ; un dispositif qui dépend d’un minuteur, non.

La revue par les pairs

Quelqu’un relit le travail de quelqu’un d’autre avant qu’il compte comme fini.

La condition : le relecteur doit pouvoir dire non. Réellement, sans que ça coûte socialement.

La panne : entre camarades qui déjeunent ensemble, dire « ce n’est pas clair » est cher, et « c’est bien » est gratuit. La revue devient une formalité de validation, et son coût — le temps de lecture — est intégralement perdu.

Le correctif : demander des questions plutôt qu’un verdict. « Note trois choses que tu n’as pas comprises » est une consigne qu’on peut remplir sans attaquer personne, alors que « dis si c’est bien » oblige à porter un jugement sur une personne qu’on voit tous les jours.

S’expliquer mutuellement

Chacun explique aux autres la partie qu’il a travaillée.

La condition : un écart faible entre celui qui explique et celui qui écoute.

La panne est contre-intuitive : c’est l’expert qui explique mal. Quelqu’un qui maîtrise a oublié ce qui coince, saute les étapes devenues évidentes pour lui, et perd son auditoire sans s’en rendre compte. Celui qui a compris la veille, lui, se souvient exactement d’où il était bloqué.

C’est ce qui rend cette technique précieuse en TP et qui devrait vous décomplexer : vous êtes souvent mieux placé que moi pour expliquer à votre voisin. Pas malgré votre niveau — à cause de lui.

Le bénéfice principal n’est d’ailleurs pas pour celui qui écoute. Expliquer oblige à mettre en ordre, et l’ordre révèle les trous. On découvre ce qu’on croyait savoir au moment où on essaie de le dire.

Le codéveloppement

Un groupe travaille à tour de rôle sur le problème réel de l’un d’entre eux — le cadre d’Adrien Payette et Claude Champagne, déjà croisé ici avec ses trois règles : authenticité, bienveillance, confidentialité.

La condition : le groupe pose des questions, il ne donne pas de solutions.

La panne est immédiate et quasi systématique la première fois : quelqu’un expose son problème, et dans les trente secondes le groupe propose des solutions. Le client cesse alors de travailler — il reçoit, il trie, il se défend. Or tout l’intérêt du codev est que la personne qui a le problème réfléchisse devant les autres, pas qu’elle écoute leurs idées.

C’est la technique la plus exigeante de la liste et la plus rentable quand elle tient. Elle mérite son propre article — celui-ci arrive.

Le puzzle

Le seul dispositif de la liste qui règle la question au lieu de la surveiller.

Chacun reçoit un morceau que personne d’autre n’a. On se réunit d’abord entre porteurs du même morceau pour le maîtriser, puis on retourne dans son groupe d’origine, où l’on est seul à le détenir. Le groupe ne peut pas produire son résultat sans écouter chacun de ses membres — non par principe, par construction.

Le procédé a été mis au point par le psychologue social Elliot Aronson en 1971, à l’université du Texas à Austin, et pas du tout pour des raisons pédagogiques¹ : les écoles de la ville venaient d’être déségrégées, les élèves se retrouvaient pour la première fois dans les mêmes classes, et l’hostilité entre groupes rendait tout travail commun impossible. Aronson a cherché une structure où coopérer ne serait pas une consigne morale mais la seule façon de s’en sortir. Les mesures qui ont suivi ont montré que ça marchait — sur les résultats scolaires comme sur les relations entre élèves².

Reportez la question du début : puis-je faire ma part seul ? Ici, non — et c’est écrit dans la distribution des documents, pas dans le règlement.

Ce que dit la recherche, et ce qu’elle ne dit pas

Ces techniques sont étudiées depuis cinquante ans, et il serait malhonnête de vous les présenter comme des recettes éprouvées.

Le puzzle a été repassé en revue en 2023, sur 69 études³. Le résultat principal n’est pas un effet spectaculaire : c’est l’inconstance. Les effets varient fortement d’une étude à l’autre — sur les résultats scolaires, la motivation, les relations entre élèves, l’estime de soi. Les auteurs pointent plusieurs facteurs derrière cette variabilité : la taille des échantillons, la diversité des élèves, le type de contenu enseigné.

Le binôme au clavier a subi un test sévère : 295 développeurs professionnels, seuls ou en binôme, sur des tâches de modification réelles⁴. L’expérience ne montre aucun gain général — ni sur le temps, ni sur la proportion de solutions correctes. Le détail est plus utile que le résultat d’ensemble : le binôme va plus vite quand la tâche est simple, et produit du code de meilleure qualité quand elle est complexe.

D’où une consigne pratique qu’on vous donnera rarement : ne vous mettez pas à deux sur ce qui est facile. Mettez-vous à deux sur ce qui vous fait peur.

Et une lecture — que je vous donne comme une lecture, pas comme la conclusion des auteurs : une technique dont l’effet dépend d’une condition produit exactement ce profil-là, de grands écarts d’une étude à l’autre. Ce qui varie n’est peut-être pas tant la technique que le fait que sa condition ait été tenue ou non.

C’est aussi pourquoi cet article est construit sur les conditions plutôt que sur les techniques. Personne ne peut vous promettre qu’un dispositif marchera. On peut vous dire à quoi reconnaître qu’il est en train de ne pas marcher.

Ce que les cinq ont en commun

Relisez les conditions : alternance réelle, possibilité de dire non, écart de niveau faible, questions plutôt que solutions, morceau unique.

Aucune n’est un trait de caractère. Ce sont toutes des propriétés du dispositif, et c’est une bonne nouvelle : on ne corrige pas un travail de groupe en demandant aux gens d’être plus impliqués. On le corrige en changeant la structure, ce qui prend dix minutes et ne demande de vertu à personne.

D’où la seule question à se poser, la prochaine fois que vous êtes quatre autour d’une table avec un rendu à produire :

Qu’est-ce qui, dans ce que nous venons de décider, m’empêche de repartir faire ma part tout seul ?

Si la réponse est « rien », vous n’avez pas encore commencé à travailler ensemble. Vous avez réparti.

Références