6 évolutions majeures de la gestion de projet informatique

L’évolution de la gestion de projet en informatique

Au même titre que l’informatique, la gestion de projet en informatique, a beaucoup évolué ces dernières années ! Que ce soit en termes de taille de projet, d’organisation, de méthodologie ou encore de communication, les codes ont été bouleversés !

Dans cet article, nous vous proposons de faire un petit saut en arrière, et de confronter les retours d’expérience de nos chefs de projet informatique les plus jeunes et les moins jeunes !

Pour écouter le podcast, c’est ici :

Evolution #1 : La taille des projets

Des grands...

Si on remonte plus de 20 ans en arrière, les temps de réalisation de projets étaient très longs (minimum 12 mois). Et pour cause, si on ne faisait pas de grands projets de plusieurs milliers de jours, on ne faisait pas de projet. Nous réalisions principalement des projets pharaoniques qui souvent, n’arrivaient pas complètement à l’heure, pas vraiment dans le budget, et qui, finalement, étaient assez loin de ce que nous avions imaginé au départ.

... Aux petits projets

Aujourd’hui, en 2020, plus personne ne se lance dans d’immenses projets en un seul bloc ! On a plutôt tendance à découper les grands projets, en petits morceaux de projets ! Au final, d’une vision globale, on réalise encore de grands projets, simplement, on le fait différemment.

Evolution #2 : Les méthodologies

Les attentes des clients ont changées

Pour coller à la logique de grand projet, nous avions une méthodologie adaptée : le bon vieux cycle en V !

Et il faut bien avouer, c’était une mécanique qui marchait plutôt bien au vu de la durée des projets (12 , 18 ou encore 24 mois).

Avec l’évolution de l’informatique et des besoins, nous ne sommes plus du tout dans ces mécaniques-là pour deux raisons :

• Les projets sont plus courts
• La notion d’espace temps n’est plus la même

« Aujourd’hui, aucun de nos grands clients ne partirait sur un projet monolithique à 2 ans en disant : je n’ai pas de livrable intermédiaire et on y va ! »

Et pour cause, nous avons tout segmenté ! L’attente et les besoins des clients sont différents, ils veulent des produits beaucoup plus rapides.

Ca va faire un peu "vieux con" de dire ça, mais avant, un projet informatique était développé pour 30 ans. Maintenant, on est plutôt dans une logique "test & learn" : on fait du code, on teste, on voit si ça fonctionne, on utilise le code tel qu’il est imaginé et puis on enrichit l’application de fonctionnalités diverses et variées au fur et à mesure.

C’est justement le fait que nous n’ayons plus les mêmes attentes et les mêmes modes de fonctionnement qui a influencé l’émergence des méthodologies agiles actuelles.

Le Cycle en V, faut-il tout jeter ?

« Il ne faut pas tout jeter avec l’eau du bain »

Avec le cycle en V, on a fait de belles choses ! La structuration qu’on retrouve avec les cycles en V (savoir facilement où on se trouve dans le projet, savoir pourquoi on fait telle ou telle tâche, ...), c’est un bel apport !

Depuis, il est vrai que nous avons pas mal travaillé sur les méthodes agiles. Ces méthodes amènent des bonnes réponses sur les sujets qui sont plus courts, plus détaillés, plus fins, grâce notamment, à des mécanismes itératifs (on fait une première version et, si elle marche bien, on la conserve et on l’enrichit !)

Pour autant, dans les projets informatiques, on ne fait le choix aujourd’hui de faire soit une méthodologie, soit une autre. Nous sommes dans une époque où finalement, on opère dans nos projets un mix entre plusieurs méthodologies. On prend le meilleur des deux mondes, en fonction des objectifs du projet !

Le fantasme des spécifications : envolé ?

Du côté des chefs de projet les plus jeunes chez nous, il y a un vieux fantasme de se dire qu’à une époque, une belle et grande époque, on avait la possibilité de se projeter sur du long terme et on disposait de spécifications bien écrites et claires ! Le rêve de tout développeur finalement ;) !

Comme les applis allaient durer 20 ans, il y avait effectivement des grands cahiers de spécifications, les cahiers de recette étaient également incontournables, mais après, quand le client voulait faire une évolution, c’était plus que compliqué !

Alors, oui, aujourd’hui, on fait toujours des spécifications, mais elles sont beaucoup plus courtes, et changent régulièrement !

Et les recettes ?

Avant, le mécanisme était le suivant : la réalisation des développements durait des mois, on livrait, et il y avait une phase de recette avec toute une équipe de recetteurs, munis de cahiers de recettes.

Aujourd’hui, les phases de recettes s’inscrivent dans une démarche beaucoup plus itérative, dans laquelle, les phases de recettes avec les utilisateurs sont déjà intégrées dans le développement du projet. Il n’y a pas de rupture dans la chaine !

Evolution #3 : les cycles projets

On l’a dit, le rapport au temps est différent ! Un porteur de projet ne peut pas se permettre aujourd’hui de dire que pendant 24 mois, on développe, et qu’entre temps, il ne va rien se passer, on ne va rien livrer. Parce que 24 mois aujourd’hui, c’est long, beaucoup de choses peuvent changer, et peut-être même que le porteur de projet ne sera même plus à ce poste... Ça va tellement vite, que les délais actuels sont plutôt de l’ordre de quelques mois au maximum.

A ce jour, les clients préfèrent avoir une première version qui donne une première étape tout de suite ; plutôt que d’attendre des mois pour avoir une solution complète.

A cela, on rajoute également un impératif de taille : l’évolution technologique ! La majorité des frameworks et des technologies sont alignées sur des cycles de vie d’environ 6 mois et in fine, on est en quelque sorte obligés de suivre ces cycles pour réaliser les applications !

Evolution #4 : la taille des équipes

La taille des projets et les méthodologies ont évoluées... la taille des équipes également !

La taille des équipes s’est fortement réduite ! C’est finalement aujourd’hui assez rare d’avoir des équipes avec 20 développeurs. On essaye plutôt de faire des équipes assez compactes, petites et pilotables de 5 développeurs au maximum. Parce que, quand vous avez des plateaux de 20 développeurs et qu’il faut les faire travailler de manière commune sur un projet, c’est assez compliqué et il y a de fortes chances qu’il y ait un pourcentage de l’équipe qui ne soit pas d’une grande efficacité...

Aujourd’hui, on a des projets beaucoup plus mesurés, plus humains, qu’on peut piloter !

Evolution #5 : la complexité du code n’est plus la même

Aujourd’hui, l’expressivité du code fait qu’aujourd’hui on peut développer beaucoup plus de choses, beaucoup plus rapidement ! Mais, ça sous entend 2 choses :

• le développeur doit être pleinement motivé : si ce n’est pas le cas, son efficacité va être très basse, voire nulle.
• le développeur doit être en pleine capacité technique

Réunir ces 2 critères, ce n’est pas une mince affaire ! En effet, des années en arrière, vous aviez moins de technologies à maitriser. On pouvait donc plus facilement remplacer un développeur par un autre…

Aujourd’hui, c’est plus compliqué de changer un développeur sur un projet car la stack technologique n’est pas toute à fait la même, et parce qu’il n’existe plus cette phase projet durant laquelle on peut mettre 15 jours pour embarquer le développeur dans un projet... il faut que ce soit rapide et efficace ! Et cela rajoute une contrainte de la méthodo agile sur les projets !

Evolution #6 : La communication et l’organisation avec le client

Parmi les grands principes qui ont changé, il y a celui de la communication et de l’organisation ! Historiquement, il y avait une barrière très étanche avec d’un coté les utilisateurs, d’un autre les informaticiens, d’un autre les concepteurs, etc. Tout le monde se parlait de temps en temps, dans des organes bien déterminés et on doit bien l’avouer... le moins possible ! Chacun pensait bien savoir ce qu’il avait à faire et n’avait pas forcément envie de rentrer en interaction avec les autres "groupes".

Les nouvelles méthodes de management de projet ont gommé cela, et ont fait en sorte d’avoir une équipe projet instantanée : une équipe qui travaille ensemble, dans laquelle il y a les développeurs, les utilisateurs, etc. C’est d’ailleurs le job d’un bon directeur de projet aujourd’hui : réussir à faire travailler tout ce monde en parfaite autonomie et harmonie ( alors qu’ils n’ont pas forcément les mêmes codes, les mêmes attentes ou les mêmes enjeux) .

La réussite des méthodes actuelles repose sur ce dernier point : travailler ensemble, bien s’entendre en permanence, communiquer day to day, etc. Alors oui, il y a encore des jalons, des process, mais on a fluidifié au maximum cette gestion de projets via notamment la réalisation de sprints !

Evolution de gestion de projet informatique, et après ?

On l’a vu, la gestion de projets a énormément évolué ces 20 dernières années, et ce, à plusieurs niveaux ! Mais qu’en est-il de la gestion de projet de demain ?

Pour nous, la gestion de projet de demain n’est pas figée... surtout pas ! Parce que tout bouge, que ce soit au niveau des technologies, des attentes des entreprises, des organisations des clients... les outillages seront différents !

C’est forcément un sujet qu’on remet en permanence en réflexion. Et c’est d’ailleurs ce qui rend le job passionnant : ce n’est pas une science exacte, c’est empirique ! Cela évolue avec les usages, l’air du temps, et si vous voulez notre avis, on a pas fini d’apprendre ! Les projets de demain, les modes de gouvernance ne sont pas encore définis...