Passer au playerPasser au contenu principal
Marris Consulting
  • il y a 16 minutes
Module 1 d'une série de 4 vidéos sur le Management de Projet par la Chaîne Critique : Problèmes du management de projet classique.

Dans ce premier module, Philip Marris passe en revue les problèmes récurrents rencontrés avec la gestion traditionnelle de projets.

Ces difficultés sont en quelque sorte les déclencheurs ayant conduit au développement de la Chaîne Critique.

Pourquoi toutes les avances s'évaporent et les retards se cumulent. L'erreur du micro-management. Pourquoi respecter les dates des jalons de chaque tâche empêche de terminer un projet à l'heure. Etc.

Marris Consulting est une société de conseil focalisée sur les opérations et le management de projet. Notre devise: Des Usines, des Hommes et des Résultats.

Catégorie

📚
Éducation
Transcription
00:16Pour bien comprendre la pertinence de la solution chaîne critique, il faut se rappeler d'où on vient en termes
00:22de management de projet.
00:23Dans les années 1950, les premières approches de gestion de projet ont émergé, de Critical Path Management et de PERT,
00:35Program Evaluation and Review Technique, et celle-ci était tout à fait pertinente par rapport à l'environnement de l
00:42'époque, mais on mal vieillit.
00:45Pourquoi ? Parce que tout simplement le niveau d'exigence qu'on a dans le domaine des projets est nettement
00:53plus élevé qu'à cette époque-là.
00:55Et donc le temps dont on dispose pour terminer un projet et les moyens, les ressources dont nous disposons pour
01:01les faire sont bien plus exigeants que par le passé.
01:05Et donc essayer de rester dans le mode de production traditionnel dans l'environnement d'aujourd'hui, c'est en
01:12fait demander aux gens de courir là où ils marchaient avant.
01:16Et dans cette accélération, dans cette course, finalement l'ensemble des organisations tombent en vrille et ça devient une véritable
01:24cacophonie.
01:25Donc il faut réinventer l'approche même de comment on aborde les projets.
01:31Vu qu'il est de plus en plus difficile de terminer ces projets à l'heure et qu'on explose
01:34de plus en plus régulièrement les budgets, on cherche à renforcer l'efficacité du management des projets.
01:40Et une des façons de faire, c'est de détailler de plus en plus les tâches.
01:45Une des dérives qu'on rencontre dès que les projets sont un peu conséquents, c'est d'essayer de traiter
01:51encore plus dans le détail.
01:54Un projet qui va durer deux mois ou deux ans va comprendre mille tâches, dix mille tâches, et des tâches
02:01qui parfois ne sont prévues que sur une durée d'une journée.
02:04Et on va ensuite, lors de l'exécution, essayer de suivre le déroulement de toutes ces tâches. Est-ce qu
02:09'elles sont finies ? Est-ce que tout s'est bien passé ?
02:12Et donc on va avoir une organisation d'administration du projet, de suivi du projet qui est énorme, pouvant consommer
02:1910, 20, 30% des ressources à suivre le projet.
02:23Et donc pas à le faire, y contribuer. Ce qui va augmenter les coûts et en plus ne va pas
02:30permettre, comme vous verrez tout à l'heure, de terminer à l'heure.
02:34Vous comprendrez à travers cette série de vidéos les résultats business de la chaîne Clétic. Terminer ses projets à peu
02:42près deux fois plus rapidement, faire deux fois plus de projets par an,
02:45ou être deux fois plus efficace dans la réalisation des projets, et serrer sur le gâteau, terminer à peu près
02:50tous ses projets à l'heure.
02:50Mais au-delà de ces résultats quantitatifs, il y a un impact qualitatif significatif, et qui plaît énormément aux entreprises,
02:58qui est d'améliorer les conditions de travail dans les équipes qui travaillent sur les projets.
03:02En effet, aujourd'hui, moi qui travaille dans tous les différents départements des entreprises,
03:06je considère que ceux qui sont concernés par les projets sont souvent celles qui souffrent le plus,
03:11dans lesquelles on trouve le plus de situations difficiles, de burn-out et de conditions difficiles de travail.
03:17Donc, la chaîne Clétic permet d'améliorer de manière significative la qualité de vie,
03:24et de permettre aux entreprises de consacrer beaucoup plus de temps à des sujets très importants,
03:29comme l'amélioration des compétences, des capabilités, des standards, et ainsi de suite.
03:36Rappelons, si nécessaire, où nous en sommes aujourd'hui dans les performances en termes de management de projets.
03:43Voici les résultats d'une étude de 2012 par l'éminent PMI, Project Management Institute,
03:50qui montre le genre de performances qu'on obtient à travers le monde dans le management de projets,
03:55et vous voyez que les résultats sont décevants.
03:59En fait, quelque part, aujourd'hui, quand on démarre des projets, on démarre presque perdant.
04:03On se dit, de toute façon, c'est un projet, et puisque c'est un projet, il va terminer en
04:09retard,
04:09on va exploser les budgets, et probablement on sera obligé de renier des spécifications d'origine
04:14par manque de temps vers la fin du projet.
04:17Donc, essayons de comprendre pourquoi.
04:21Les projets, dans leur ensemble, ont été décomposés en différentes tâches élémentaires,
04:26et on part de l'idée que si on peut s'assurer que chacune de ces tâches élémentaires se termine
04:31à l'heure,
04:32eh bien, le projet terminera à l'heure.
04:36Donc, on a un réseau de tâches dans lequel, pour chacune des tâches, on a intégré une marge de sécurité.
04:41Par exemple, une tâche dont la durée est prévue de deux jours de travail,
04:45on va rajouter deux jours de sécurité, de marge, pour s'assurer qu'on est absolument certain de terminer à
04:49l'heure.
04:50Donc, on a un réseau de tâches avec des sécurités partout,
04:54et ainsi, on se dit qu'on va terminer à l'heure.
04:56Et pourtant, on le sait bien, on voit le résultat global, ce n'est pas le cas.
05:00Donc, comment se fait-il qu'avec toutes ces sécurités, les projets terminent néanmoins en retard ?
05:05Et on va comprendre qu'en fin de compte, c'est justement parce qu'on a essayé de s'assurer
05:10que chacune des tâches terminent à l'heure, que le projet, dans son ensemble, terminera en retard.
05:16Donc, le leitmotiv, la culture générale de management de projet,
05:19c'est, en fin de compte, un pilotage serré, un micro-management par les dates
05:25et par les délais d'engagement au niveau des tâches.
05:27C'est une véritable tyrannie des dates.
05:30Effectivement, le terme anglais est révélateur.
05:33A deadline, le délai d'une tâche, vous serez mort si vous terminez après.
05:39Alors, regardons comment on détermine la durée d'une tâche.
05:42La technique la plus répandue, la plus connue, celle qui figure dans les certifications du Project Management Institute, du PMI,
05:53c'est la méthode PERT, Program Evaluation and Review Technique.
05:57Pour ce faire, on demande aux acteurs d'une tâche d'identifier trois temps.
06:03Le temps pessimiste, le temps optimiste et le temps probable.
06:07Et à partir de là, on mouline ceci dans une formule qui permet de déterminer la durée médiane pondérée.
06:13C'est-à-dire qu'on a 50% de probabilité de prendre plus de temps que cette durée
06:17et 50% de probabilité d'aller plus vite.
06:23Et c'est ça, la technique qu'on est censé utiliser.
06:25Elle est toute théorique, car effectivement, dans mon expérience, on la rencontre très très rarement dans les faits.
06:33Et pourquoi ? Parce qu'en fin de compte, elle ne survit absolument pas aux comportements managériaux.
06:39Elle est juste.
06:40Ce n'est pas que la formule contient des inexactitudes algorithmiques.
06:45Mais elle suppose que la personne est en train de travailler dans un environnement complètement neutre au niveau managérial et
06:49politique.
06:51Mais attardons-nous à l'instant sur la courbe et la forme de cette courbe.
06:56Car je répète, normalement, la durée d'une tâche devrait ressembler à ceci.
07:00Et c'est intéressant de s'en rappeler.
07:03Comme vous voyez par sa forme, on peut avoir la chance que la tâche s'est faite très vite.
07:11On a peut-être utilisé un savoir-faire, on a eu bon du premier coup, je ne sais quoi.
07:16Et à l'autre extrémité, ça peut être très très difficile.
07:19Imaginons qu'on est en train de concevoir une pièce mécanique.
07:22Elle ressemble à une pièce mécanique qu'on avait à faire la dernière fois.
07:25Sauf que les spécifications de je ne sais quelle tolérance sont tellement serrées
07:30qu'on a dû recommencer dix fois de suite avant d'arriver à la bonne réponse.
07:35Donc ça peut prendre beaucoup plus longtemps qu'on avait estimé initialement.
07:39Et la forme globale, vous la voyez, elle dit que souvent, les choses vont se passer normalement.
07:44Parfois, ça sera très bien et de temps en temps, ça sera l'enfer.
07:48Et c'est comme ça que ça devrait se passer.
07:50Mais ce n'est pas du tout ce qu'on constate dans les entreprises.
07:53Pour comprendre la différence entre la durée d'une tâche théorique et la durée d'une tâche réelle,
07:58prenons l'explication qui est donnée par Elia Ouboldrath dans son livre, justement,
08:04qui s'appelle « Chaîne critique » et qui décrit ses comportements.
08:09Il évoque deux différents syndromes, deux différents dysfonctionnements qui sont à prendre en compte.
08:17Le premier est le syndrome de l'étudiant.
08:21Et dans son histoire, il prend l'exemple d'un professeur qui, face à sa classe, va donner un devoir
08:29et il leur propose de rendre ce devoir une semaine plus tard.
08:33Alors, les étudiants râlent, on a un autre examen à telle date, etc., on ne peut pas, etc., etc.
08:40Donc, ils discutent, ils négocient et, finalement, ils décident de leur accorder deux semaines, non pas une,
08:49pour réaliser ce devoir.
08:51La question est, combien d'entre eux vont commencer à travailler le soir même sur ce devoir ?
08:59La remarque, bien sûr, c'est que très souvent, quand on a plusieurs différentes tâches à réaliser,
09:04on va subir le syndrome de l'étudiant, c'est-à-dire qu'on va commencer au dernier moment, ou
09:09en tout cas très tard.
09:10Et c'est seulement, d'ailleurs, en démarrant la tâche en question qu'on va découvrir à quel point elle
09:14est compliquée ou simple.
09:16Et donc, si on va être frappé par Murphy, par un problème, on va le découvrir au dernier moment,
09:22on n'aura absolument pas le temps de réagir.
09:25Donc, voilà, le syndrome de l'étudiant fait que, même si on a donné une durée conséquente pour réaliser une
09:32tâche,
09:32avec une marge de sécurité, vu qu'on ne commence pas tout de suite, on perd une grande partie de
09:38cette sécurité.
09:40Le deuxième syndrome est appelé le syndrome de Parkinson.
09:44Alors, selon les présentations, il est parfois décliné en sous-ensemble,
09:48mais je vais tout regrouper sous le syndrome de Parkinson,
09:50qui est, vous le savez, la loi qui dit que le travail va s'étaler pour consommer tout le temps
09:58disponible.
10:01Donc, qu'est-ce qui se passe dans le moment des projets ?
10:04Imaginons que vous êtes responsable de la réalisation d'une tâche.
10:09Prenons l'exemple de développer un morceau de logiciel, un bout de code pour un software.
10:17Donc, vous avez à réaliser ce module, ces lignes de code.
10:22Une discussion a eu lieu et une estimation a été donnée pour la durée.
10:26Vous vous mettez au travail et vous codez la chose.
10:31Vous avez de la chance, en réutilisant un code semblable d'un projet précédent,
10:37en fin de compte, vous avez réussi à faire le projet,
10:39non pas avec les dix jours qui vous étiez alloués, mais vous arrivez à le faire en trois.
10:45Super, bonne nouvelle.
10:47Donc, je l'ai naïf, vous allez voir votre responsable en disant,
10:50voilà chef, j'ai fini, voilà le code.
10:56Alors, est-ce que ça va bien se passer ?
10:59Ça ne va pas se passer comme ça.
11:00Parce que, si effectivement, il présente son travail nettement en avance,
11:08son patron va peut-être simplement accepter la chose et poursuivre sans rien changer.
11:12Mais ce qui est le plus probable, c'est que la prochaine fois,
11:16quand on vient à estimer la durée de cette même tâche,
11:21ou de quelque chose de semblable,
11:23le patron va se rappeler que la dernière fois, on est allé beaucoup plus vite que prévu,
11:28et donc, il va dire, ben, on n'a plus besoin de dix jours.
11:32On va accorder seulement quatre jours à la réalisation de cette tâche.
11:37Et donc, finalement, on refait la tâche,
11:40mais cette fois-ci, il n'est pas possible de réutiliser un code précédent,
11:43c'est un travail normal,
11:45et donc, on ne va pas pouvoir le faire dans les quatre jours,
11:48on va dériver et on va terminer en retard.
11:53Et si ça, c'est le seul problème,
11:56il peut aussi en avoir encore plus en aval.
11:59Imaginons donc que j'ai donné mon projet avec trois jours d'avance,
12:03le patron a pris la chose et a passé sa ligne de code
12:07à l'étape suivante, à la tâche qu'il doit prendre la suite.
12:11L'acteur qui réalise la suite va donc avoir cette tâche qui lui arrive avec une semaine d'avance.
12:19Et que va-t-il faire ?
12:21Ben, probablement, il va la mettre de côté
12:25et seulement commencer sept jours plus tard.
12:27Parce que, normalement, il est déjà occupé à faire autre chose.
12:31Donc, il ne peut pas la prendre tout de suite.
12:36Et s'il a cette tâche qui est en avance,
12:37il y en a certainement d'autres dans sa charge de travail
12:40qui sont tout juste à l'heure, voire peut-être déjà en retard.
12:44Donc, la tâche qui avait pris cette jour d'avance,
12:47en fin de compte, cette avance va s'évaporer,
12:49elle va disparaître.
12:51Et le projet va reprendre à date.
12:56Bref, avec des comportements comme ceci,
12:59on est dans un mécanisme infernal
13:01dans lequel les avances disparaissent,
13:05elles s'évaporent,
13:07et seulement les retards peuvent se cumuler à travers le système.
13:11Donc, toutes les sécurités qu'on avait installées,
13:12en fin de compte, ne servent à rien.
13:14Et c'est ainsi que, malgré toutes ces sécurités,
13:17les projets vont terminer en retard.
13:19Donc, nous avons un système dans lequel
13:21les avances disparaissent et les retards se cumulent.
13:25Ceci est amplifié par le phénomène d'idée
13:27des points d'intégration
13:28que tous ceux qui font des simulations de Montecarlo
13:31dans les projets connaissent bien.
13:33Imaginons qu'il y ait trois tâches
13:36qui, ensemble, vont donner différents livrables
13:38qui sont nécessaires pour la tâche suivante.
13:40Donc, la tâche suivante a besoin
13:44d'avoir les livrables de trois tâches en amont.
13:48Qu'est-ce qui peut se passer ?
13:49Eh bien, imaginons qu'il y a une tâche
13:51qui est terminée avec trois jours d'avance,
13:52une autre qui est terminée exactement à l'heure
13:54et la troisième qui est terminée avec dix jours de retard.
13:56Eh bien, bien sûr, la tâche suivante
13:58ne peut que commencer avec dix jours de retard.
14:02Bref, c'est le pire des différents retards
14:05qui va se cumuler à travers le système.
14:07Et des points d'intégration sont nombreux dans les projets.
14:10Pour prendre un autre exemple statistique,
14:12si vous avez cinq tâches,
14:14chaque une d'entre elles avec 50% de probabilité
14:16de terminer à l'heure,
14:17la probabilité que vous ayez toutes les tâches terminées
14:19est seulement de 3% de terminer toutes les tâches à l'heure.
14:23Parlons maintenant d'un autre aspect
14:26du management de projet
14:27qui est peut-être le principal fléau
14:29dans les non-performances.
14:31Parlons maintenant de ce qui est probablement
14:33le principal fléau dans la performance des projets,
14:37qui est les problèmes de multitâches.
14:40Il y a différentes façons de l'expliquer,
14:41mais une d'entre elles,
14:42c'est qu'on devrait, on peut,
14:45avec un logiciel de gestion de projet,
14:48faire un nivellement des tâches,
14:50c'est-à-dire que s'assurer dans les plannings
14:51qu'une personne n'a jamais deux choses à faire à la fois.
14:54En réalité, c'est très rarement fait.
14:57On va supposer que les différents acteurs
14:59vont se débrouiller sur le terrain.
15:02Donc on va planifier qu'une personne
15:04va faire deux tâches simultanément.
15:08Donc la personne voyant ça,
15:09elle va dire, ok, c'est ce qu'on me demande,
15:10je vais le faire,
15:11et il prévoit de passer, je ne sais pas moi,
15:13une journée sur le premier projet,
15:14le deuxième jour sur le deuxième projet,
15:18et ainsi de suite,
15:19travailler l'un après l'autre.
15:20En réalité, ça va être bien pire que ça,
15:24parce qu'ils vont se retrouver déchirés
15:26par les différents acteurs de chacun des projets,
15:29sollicités pour faire quelque chose
15:30sur leur projet,
15:31et nous qui faisons régulièrement des audits
15:35sur les comportements réels des personnes
15:38dans ces environnements-là,
15:40il n'est pas rare de trouver que la personne
15:41va, en fin de compte, changer de tâche
15:4360 fois dans la journée,
15:45bref, travailler 5-10 minutes à la fois
15:47sur un projet avant de passer à un autre.
15:50Et ceci est extrêmement destructeur de performance,
15:54parce que, notamment,
15:56il y a un temps de setup,
15:59un temps de transition,
16:00avant de reprendre un dossier,
16:02il faut se remettre dans le bain,
16:05et ça va consommer beaucoup de temps.
16:09Dans nos formations,
16:10chaîne critique,
16:11dont ceci est un condensé,
16:14nous jouons le jeu du multitâche.
16:17C'est quelque chose de très simple,
16:18nous donnons à chacun des participants
16:22une feuille de papier,
16:23ou plutôt quatre feuilles de papier
16:24à graffer ensemble.
16:25Sur la première feuille,
16:26il y a les lettres de l'alphabet,
16:29A, B, C, D,
16:30la deuxième,
16:31les chiffres pairs,
16:322, 4, 6,
16:34la troisième,
16:35écrire la chaîne critique,
16:36et sur la quatrième,
16:37les chiffres impairs.
16:39Et on leur demande de remplir,
16:41en fin de compte,
16:42ces différentes feuilles,
16:43l'une après l'autre.
16:45D'abord l'alphabet,
16:46ensuite les chiffres pairs,
16:48ensuite la chaîne critique,
16:49la quatrième tâche.
16:50on mesure le temps qu'ils prennent,
16:53ensuite on recommence le jeu,
16:54mais en mode multitâche,
16:55c'est-à-dire qu'on leur demande
16:56de faire d'abord le chiffre pair,
16:59ensuite la lettre de l'alphabet,
17:01ensuite la chaîne critique,
17:03et enfin le chiffre impaire.
17:04Et donc ils tournent les pages,
17:06ils tournent les pages,
17:07et ils remplissent.
17:08Quand on fait ça,
17:08juste sur cet exemple,
17:10on a le résultat suivant.
17:13Le temps qu'il faut
17:14pour réaliser l'ensemble des tâches
17:16est multiplié par 3.
17:18Et pire,
17:18on trouve énormément d'erreurs,
17:20c'est-à-dire que les gens
17:21ne se rappellent plus leur alphabet,
17:23ne se rappellent plus les chiffres pairs,
17:24bref, on a beaucoup d'erreurs.
17:26Et beaucoup de stress en fait.
17:29Et on joue ce jeu,
17:30parce que je pense que c'est très révélateur
17:31des mondes des projets,
17:33dès qu'on est à gérer des portefeuilles
17:35en mode multitâche.
17:36Et je répète,
17:37je pense que c'est le fléau
17:40le plus destructeur dans le monde des projets.
17:43Donc voilà l'environnement,
17:46voilà le système
17:47dans lequel opèrent les différents acteurs.
17:51Un monde extrêmement malsain
17:53dans lequel il est très difficile
17:54de connaître les priorités,
17:56dans lequel on vous demande de faire A,
17:58ensuite B, ensuite C.
18:01Et en fait,
18:02on finit par accepter
18:04qu'un bon chef de projet
18:07c'est quelqu'un
18:08qui est très bon négociateur
18:11ou qui a un bon management par décibel
18:13ou qui est assez machiavélique
18:14pour pouvoir s'assurer
18:15que son projet avance plus vite
18:18que les autres.
18:20Sans parler du projet du patron,
18:21le projet du patron du patron,
18:23le projet, etc.
18:24Donc on a une cacophonie énorme.
18:26Donc tout ce mode de management de projet
18:28est basé sur une idée
18:30qui semblait initialement juste et normale
18:32qui est que si on veut terminer
18:34ses projets à l'heure,
18:36il faut s'assurer que chacune des tâches
18:37élémentaires constituant ses projets
18:39termine elle aussi à l'heure.
18:42Mais comme vous voyez,
18:43même si en théorie ce serait possible,
18:45en réalité on arrive exactement
18:47qu'au résultat inverse.
18:48Car les gens prennent des sécurités,
18:50les gaspillent
18:50et on retrouve le système
18:52que je viens de décrire.
18:53Alors une autre conséquence
18:55regrettable de cette situation
18:56où tous les temps sont faux,
18:58on ne sait plus si les tâches
18:59sont en avance,
18:59on en retard,
19:00on pointe les temps d'ailleurs
19:01n'importe où,
19:03c'est celui qui hurle le plus fort
19:05qui fait avancer le projet au mieux,
19:07et ainsi de suite.
19:08On finit par se dire
19:10que planifier un projet
19:11avant même de le démarrer,
19:13planifier un projet
19:14avec diligence et rigueur,
19:16c'est perdre du temps.
19:18Puisque de toute façon,
19:19il sera mort avant même
19:21que l'encre sèche.
19:24Donc on finit par
19:25ne plus avoir
19:26des beaux plannings.
19:28On a des plannings
19:30dans lesquels on trouve
19:30par exemple
19:31qu'il n'y a même plus de rigueur
19:32dans l'identification
19:34des successeurs
19:35et des prédécesseurs
19:35des tâches.
19:36C'est-à-dire que vous allez avoir
19:37des tâches qui flottent
19:37dans votre TMS Project
19:40sans qu'il y ait
19:41un prédécesseur
19:42ou sans qu'il y ait un successeur.
19:44Très régulièrement,
19:45on audite des projets
19:46et on trouve qu'il y a 20%
19:47de tâches qui sont
19:48comme ça perdues
19:50dans le système.
19:51Autre chose qui est devenue
19:52aujourd'hui très répandue,
19:54c'est qu'on ne se préoccupe plus
19:55d'identifier les ressources
19:57nécessaires pour réaliser
19:58une tâche
19:59parce qu'on n'a pas
20:01la moindre idée
20:01de qui va faire la tâche
20:02plus tard,
20:03parce que vous avez vu
20:04comment les choses
20:05vont réellement être exécutées.
20:07Et enfin,
20:07plus étonnant encore,
20:08nous avons régulièrement
20:09constaté en regardant
20:10des projets
20:10que même les livrables,
20:13ce qui doit sortir
20:14de telle tâche,
20:15ce qui doit entrer
20:16dans une telle autre tâche,
20:18ne sont pas clairement
20:20explicité
20:22et on a
20:24des vraies incohérences
20:25où entre deux étapes
20:27d'un projet,
20:28il y a quelqu'un qui va dire
20:28« mais ce n'est pas ça
20:30que je voulais ! »
20:31ou un autre qui va dire
20:32« mais pourquoi tu me dis ça ?
20:33je n'en ai pas besoin. »
20:35Avant de poursuivre
20:35et expliquer comment fonctionne
20:37la chaîne critique,
20:37j'aimerais juste souligner
20:38un point important.
20:40Les différents éléments,
20:42par exemple,
20:45explicités par le
20:45Project Management Institute
20:47dans son PMBOK,
20:51sur la manière professionnelle
20:53de gérer des projets,
20:55tout est juste.
20:57On n'est pas en train
20:58de remettre en cause
20:58tout ce qui est écrit
20:59sur comment on décrit
21:00des tâches,
21:01comment on gère les risques
21:02et tous les autres
21:03éléments du corpus.
21:06Au contraire,
21:07vous verrez que
21:08la chaîne critique
21:08vous permet enfin
21:10de mettre en œuvre
21:11et d'utiliser correctement
21:12tout ce qui est prévu
21:14dans ce corpus de knowledge.
21:18Nous avons fait le tour
21:19du management
21:20de projets traditionnels
21:22et nous allons maintenant
21:23voir comment
21:24la prochaine critique
21:26permet néanmoins
21:27de reprendre le contrôle
21:28de tout ça
21:28et de faire en sorte
21:30que ces projets
21:30aillent plus vite
21:31qu'on en fasse plus
21:32et qu'on les termine
21:33tous à l'heure.
21:33et qu'on en fasse plus vite.
21:48Sous-titrage Société Radio-Canada

Recommandations