Or­ga­ni­sa­tion Ges­tion de pro­jet : le dis­cours des mé­thodes

Grâce no­tam­ment aux ap­proches agiles et à leurs dé­ri­vées mé­tho­do­lo­giques, la conduite de pro­jet in­for­ma­tique s’est consi­dé­ra­ble­ment re­nou­ve­lée de­puis quinze ans. Les pre­miers bi­lans sont po­si­tifs concer­nant la te­nue des dé­lais, des bud­gets et la sa­tis­fact

IT for Business - - ENQUÊTE -

Pa­ru en 2001, le ma­ni­feste Agile était si­gné par dix-sept ex­perts du dé­ve­lop­pe­ment lo­gi­ciel, par­mi les­quels les pères des mé­thodes Scrum, Ex­treme Pro­gram­ming, ou DSDM (Dy­na­mic sys­tems de­ve­lop­ment me­thod), la ver­sion an­glaise de la mé­thode RAD (Ra­pid ap­pli­ca­tion de­ve­lop­ment). Seize ans après, ces ap­proches sont-elles dé­jà en­trées dans l’âge adulte ? D’ores et dé­jà, elles ont ré­vo­lu­tion­né les pra­tiques de conduite de pro­jet. Au me­nu, re­dé­fi­ni­tion des ob­jec­tifs et re­dis­tri­bu­tion des rôles, rien que ce­la !

« L’évo­lu­tion est pro­fonde dans les en­tre­prises » , es­time Guy Le­turcq, di­rec­teur gé­né­ral et co­fon­da­teur de TNP, une so­cié­té de conseil spé­cia­li­sée dans la trans-

for­ma­tion des en­tre­prises, qui in­ter­vient no­tam­ment sur la ma­nière de pro­duire des ap­pli­ca­tions. « Nous sommes pas­sés des mé­thodes re­po­sant sur des cycles en V, comme Me­rise ou Axial, avec des ou­tils d’ac­com­pa­gne­ment comme les dia­grammes de Gantt pour la ges­tion des plan­nings et les mo­dèles de description lo­gique des don­nées (MLD), à des ap­proches qui re­posent prin­ci­pa­le­ment sur des ité­ra­tions » .

« Les grands groupes avec les­quels nous tra­vaillons, par exemple dans le sec­teur ban­caire, ont in­té­gré ces nou­veau­tés mé­tho­do­lo­giques, mais doivent com­po­ser avec leur exis­tant » , com­plète Me­j­di Hi­zem, son bras droit, res­pon­sable du dé­par­te­ment trans­for­ma­tion du SI. « Ce pa­tri­moine est au moins au­tant hu­main qu’ap­pli­ca­tif » .

Tout n’est donc pas mau­vais dans les mé­thodes tra­di­tion­nelles, ne se­rait-ce que parce que de nom­breux pro­fes­sion­nels ex­pé­ri­men­tés les maî­trisent à la DSI, et que le MCO du le­ga­cy dé­pend en­core lar­ge­ment d’eux. Et c’est en gar­dant ces ex­per­tises sur les ap­proches — dites en cas­cade, adap­ta­tives, du che­min cri­tique, du pro­ces­sus uni­fié ou de la chaîne cri­tique, pour ne ci­ter que les plus connues —, que la DSI res­te­ra ca­pable de dé­ployer la meilleure com­bi­nai­son pos­sible de mé­tho­do­lo­gies face aux dé­fis lan­cés par les mé­tiers sur le plan fonc­tion­nel, et par le le­ga­cy cô­té tech­nique.

Pour au­tant, les mé­thodes agiles ont clai­re­ment le vent en poupe, en par­ti­cu­lier au­près des jeunes in­for­ma­ti­ciens, et ont réus­si à ir­ri­guer toutes les or­ga- ni­sa­tions et sur­tout, tous les « mé­tiers » de l’in­for­ma­tique, de­puis les phases de concep­tion jus­qu’à la mise en ex­ploi­ta­tion avec De­vops et même la main­te­nance grâce à Kan­ban.

SMALL IS BEAUTIFUL

D’après l’étude an­nuelle du Stan­dish Group pa­rue à l’au­tomne 2016, les pro­jets de dé­ve­lop­pe­ment me­nés avec ces ap­proches réus­sissent dans 39 % des

cas : ils rem­plissent alors, dans les dé­lais et au bud­get pré­vu, les at­tentes des uti­li­sa­teurs. Tan­dis que les pro­jets me­nés avec des mé­thodes plus tra­di­tion­nelles ne ren­contrent le suc­cès que dans 11 % des cas. Autre dif­fé­rence mar­quante dans le Chaos Re­port du Stan­dish, le taux de réus­site des « pe­tits »

pro­jets dé­passe les 60 % quand les grands pro­jets at­teignent pé­ni­ble­ment les 6 %. Lo­gique, puisque les pro­jets agiles sont prin­ci­pa­le­ment me­nés par de pe­tites équipes.

Mais alors, faut-il aban­don­ner la par­tie avec les plus grands pro­jets, no­tam­ment ceux qui touchent au le­ga­cy ? Les avis di­vergent quelque peu. « La meilleure pra­tique consiste à ou­vrir le noyau ap­pli­ca­tif his­to­rique aux ap­pli­ca­tions dé­ve­lop­pées en mode Agile, grâce à des API. Ce­la ga­ran­tit la sta­bi­li­té du le­ga­cy, tout en per­met­tant d’ac­cé­lé­rer la pro­duc­tion de nou­velles fonc­tion­na­li­tés » , consi­dère Guy Le­turcq. Son confrère Da­vid Fer­rei­ra, évan­gé­liste De­vops et agi­li­té chez Cap­ge­mi­ni, pré­co­nise quant à lui une « sor­tie du ga­rage » pour les mé­thodes agiles, « afin qu’elles puissent en­fin ser­vir l’en­semble des ob­jec­tifs des DSI, et pas seule­ment aux so­lu­tions orien­tées web » . Mais la bonne nou­velle, se­lon lui, c’est qu’il n’y a pas de contre-in­di­ca­tion, « même si le suc­cès des nou­velles ap­proches, jusque-là ré­ser­vées à des pé­ri­mètres ap­pli­ca­tifs li­mi­tés, a pu pa­ra­doxa­le­ment faire croire qu’elles ne fonc­tion­naient que dans ces uni­vers res­treints » .

DE NOU­VEAUX RÔLES, NO­TAM­MENT DE COM­MU­NI­CA­TION

Pour évi­ter les dé­per­di­tions de temps, mais aus­si évi­ter les si­los, la ma­nière de com­mu­ni­quer sur ces

pro­jets re­vêt une im­por­tance crois­sant avec leur taille. Il faut or­ches­trer les dif­fé­rentes réunions et les in­ter­ven­tions, en équi­li­brant leur poids en fonc­tion du mo­ment dans le dé­rou­lé du pro­jet. À ses dé­buts, le temps pas­sé avec les uti­li­sa­teurs est cru­cial, tan­dis qu’en pé­riode de dé­ve­lop­pe­ment, ce­lui consa­cré aux échanges avec les ex­ploi­tants de­vient es­sen­tiel.

Les mé­thodes agiles ins­ti­tu­tion­na­lisent de nou­veaux rôles, qui in­carnent les dif­fé­rents points de vue au­tour de l’ap­pli­ca­tion à pro­duire. Le fa­meux scrum mas­ter, en tant que gar­dien du temple, a pour but de sé­pa­rer la forme du fond. Le be­soin uti­li­sa­teur est dé­fen­du par le pro­duct ow­ner. Tan­dis que les contraintes tech­niques sont chez le tech lead… Mais les ar­bi­trages pri­vi­lé­gient tou­jours le point de vue du bu­si­ness.

Et le chef de pro­jet dans tout ce­la ? Il de­vient co­res­pon­sable du ré­sul­tat avec le pro­duct ow­ner. Ce­la peut ap­pa­raître comme une ré­gres­sion mais, en réa­li­té, tout change, sauf le titre ! D’abord, la dé­fi­ni­tion même des ob­jec­tifs à at­teindre — le ré­sul­tat — est mou­vante, et ad­mise comme telle tout au long du pro­jet. En­suite, il n’y a pas de fin à sa mis­sion, sauf à consi­dé­rer que la pro­duc­tion d’une ver­sion d’un pro­duit lo­gi­ciel consti­tue une fin en soi. La lo­gique veut plu­tôt que le chef de pro­jet s’ins­talle dans un rôle d’édi­teur de lo­gi­ciels, res­pon­sable de ses fu­tures évo­lu­tions tant qu’il ne change pas de poste.

« Le chef de pro­jet a en réa­li­té beau­coup à faire, pense Guy Le­turcq. Car si ces mé­thodes im­pliquent le tra­vail en pe­tites équipes, le tra­vail sur de plus grosses ap­pli­ca­tions va en mul­ti­plier le nombre, avec des ef­forts de coor­di­na­tion consi­dé­rables à four­nir » . Et comme le cycle de base reste court — de deux à quatre se­maines —, le moindre re­tard pris est dif­fi­ci­le­ment rat­tra­pable.

PÉ­NU­RIE DE « VRAIS » DÉ­VE­LOP­PEURS

Consé­quence in­at­ten­due de ces évo­lu­tions, le be­soin de vrais dé­ve­lop­peurs, au­to­nomes et ca­pables de se concen­trer sur leur pro­duc­tion de code, se fait sen­tir « et les en­tre­prises ont même ten­dance à ré­in­ter­na­li­ser » , si­gnale Med­ji Hi­zem. « Le chef de pro­jet doit s’ef­for­cer de les pro­té­ger des per­tur­ba­tions ex­ternes et de li­bé­rer leur temps de pro­duc­ti­vi­té, en op­ti­mi­sant le conte­nu, la fré­quence et la du­rée des réunions aux­quelles ils par­ti­cipent ».

On le voit, le mé­tier de chef de pro­jet ne dis­pa­raît pas, mais évo­lue. L’ac­cul­tu­ra­tion des DSI aux mé­thodes agiles va se pour­suivre dans les pro­chaines an­nées, et dé­bor­der le cadre ini­tial du dé­ve­lop­pe­ment pour ir­ri­guer jus­qu’aux équipes d’ex­ploi­ta­tion. « On voit dé­jà, dans le cloud, des ini­tia­tives réus­sies de rap­pro­che­ment entre les ex­ploi­tants et les clients mé­tiers,

qui passent no­tam­ment par la mise à dis­po­si­tion d’in­ter­faces si in­tui­tives que l’uti­li­sa­teur peut dé­clen­cher lui-même l’ins­tal­la­tion de res­sources sup­plé­men­taires » , si­gnale Da­vid Fer­rei­ra.

Quelle se­ra la fin de l’his­toire ? En toute lo­gique, il ne de­vrait pas y en avoir. Car si la for­ma­tion des ac­teurs d’un pro­jet in­for­ma­tique se concen­trait, au­pa­ra­vant, sur la maî­trise d’une ou deux grandes mé­thodes, la di­ver­si­té des ap­proches au­jourd’hui dis­po­nibles au­to­rise de bien plus nom­breuses com­bi­nai­sons de com­pé­tences. Sans comp­ter que des mé­tis­sages sont tou­jours pos­sibles avec des mé­thodes ve­nues d’autres mé­tiers de l’en­tre­prise, par exemple le Beyond Bud­ge­ting des di­rec­teurs fi­nan­ciers, pour éta­blir des bud­gets ré­vi­sables au­tant de fois que né­ces­saire. « L’heure est au­jourd’hui au best of breed mé­tho­do­lo­gique, ré­sume Da­vid Fer­rei­ra. Ce qui compte, ce n’est plus la loi, mais l’es­prit des lois » !• Fran­çois Jeanne

LE CHEF DE PRO­JET S’INS­TALLE DANS UN RÔLE D’ÉDI­TEUR DE LO­GI­CIELS

« Le suc­cès des mé­thodes agiles se tra­duit par un sur­croît de de­mande des en­tre­prises pour des dé­ve­lop­peurs au­to­nomes et per­for­mants, et par une ré-in­ter­na­li­sa­tion de ces équipes » Guy Le­turcq, di­rec­teur gé­né­ral et fon­da­teur de TNP

« Le dé­fi d’au­jourd’hui, c’est de sor­tir les mé­thodes agiles du “ga­rage” et de les uti­li­ser sur des pro­jets de grande taille, tou­chant no­tam­ment au pa­tri­moine ap­pli­ca­tif ». Da­vid Fer­rei­ra, évan­gé­liste De­vops et agi­li­té chez Cap­ge­mi­ni

« Le chef de pro­jet doit pro­té­ger le temps pro­duc­tif de ses dé­ve­lop­peurs, en li­mi­tant no­tam­ment le temps pas­sé en réunions ». Me­j­di Ha­zem, chef du dé­par­te­ment Trans­for­ma­tion du SI, TNP

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.