Durant les 25 dernières années, l’univers des technologies de l’information a connu plusieurs évolutions à différents degrés. C’est sur le plan de la méthodologie utilisée pour gérer les projets IT que les changements ont eu le plus d’impact. Le déploiement des systèmes dans les grandes structures ne s’effectuait jadis qu’en fonction d’une seule méthode, la méthode classique en V (ou en cascade). Les équipes comprenaient plusieurs membres et la hiérarchie était très présente. Les ressources étaient affectées au développement de projets longs et lourds, chronophages et très exigeants en termes d’énergie consacrée. Ce mode d’opération classique, bien que sa popularité tende à s’essouffler peu à peu, a encore la cote dans de grandes entreprises, celles notamment qui mettent en place des solutions de grande envergure sur une longue période. Mais pour la plupart des organisations, les cadres de travail Agile supplantent progressivement cette façon de procéder. Il en va de même pour le DevOps. Ces sujets, et plus encore, seront abordés dans le présent dossier.

Évolution sur le plan de la taille des projets

Il y a une vingtaine d’années, les projets informatiques s’étendaient sur de très longues périodes, douze mois au minimum. L’acceptation ou non d’un mandat était même parfois principalement basée sur sa durée. Mais souvent, ces projets interminables n’étaient pas réalisés dans les délais prescrits, ne respectaient pas les budgets établis et les résultats n’étaient pas toujours convaincants. Cette façon de faire aujourd’hui a été délaissée, on ne se lance plus dans des projets d’envergure en un seul bloc. On privilégie plutôt le découpage des grands projets en sous-projets beaucoup plus faciles à gérer. En somme, on réalise encore de grands projets mais leur traitement est pensé différemment.

Évolution sur le plan des cycles de projets

Comme mentionné précédemment, le rapport au temps dans la gestion de projets informatiques est de nos jours différent. Révolue l’époque où l’on développait pendant presque deux années sans qu’aucun produit ne soit livré ! Tout change tellement rapidement qu’à présent, les délais sont de l’ordre de quelques mois au maximum. Aujourd’hui, le client préfère obtenir une première version non finalisée du produit afin d’en avoir un aperçu plutôt que d’attendre qu’on lui fournisse une solution complète. Et à ce nouveau mode de fonctionnement s’ajoute un élément important à considérer, soit l’évolution technologique. Les technologies et les structures logicielles étant désormais alignées sur des cycles de vie ne dépassant pas six mois, les développeurs n’ont d’autres choix que de suivre ces cycles pour mettre au point leurs applications.

Évolution sur le plan de la taille des équipes

La taille et les cycles de projets ont changé au cours des années… et la taille des équipe en a fait tout autant. Si à une époque il était courant qu’une équipe de développeurs composée de vingt membres travaillent sur un seul et unique projet, la tendance est maintenant aux équipes réduites comprenant tout au plus cinq développeurs. Les projets deviennent ainsi plus faciles à piloter.

Évolution sur le plan technique

L’augmentation des plateformes mobiles, des mégadonnées et l’expressivité du code engendrent la création de projets informatiques toujours plus importants et compliqués. Évidemment, cette complexité permet de développer beaucoup plus de choses qu’auparavant et beaucoup plus rapidement. Mais elle fait aussi en sorte que le développeur doit faire preuve d’une grande célérité et d’une compétence sans failles sur le plan technique car comparativement à une époque pas si lointaine, les technologies à maîtriser sont innombrables.

Évolution sur le plan méthodologique

La méthodologie cycle en V (en Cascade ou Waterfalls) fut pendant longtemps parfaitement harmonisée à la logique de grand projet. Il s’agissait d’une mécanique hautement fonctionnelle pour les projets de longue durée (12, 18 ou 24 mois). Toutefois, dû l’évolution de l’informatique, de la durée plus courte des projets et de la notion d’espace-temps qui n’est plus du tout la même, cette approche ne fait plus l’unanimité. Les besoins et les attentes des clients ont eux aussi changé, surtout en ce qui a trait à la livraison des produits qu’ils souhaitent maintenant recevoir rapidement. Ce sont d’ailleurs ces changements qui ont influencé l’émergence des méthodologies Agile actuelles. Cette méthodologie sera détaillée plus loin. Voyons d’abord la méthodologie cycle en V.

La méthode cycle en V

La méthode de gestion de projet cycle en V, autrement nommée en Cascade ou encore Waterfall, consiste à gérer un projet informatique en passant par une liste de tâches prédéfinies à accomplir de façon linéaire et séquentielle. Chaque étape est destinée à des tâches précises et dépend des résultats de l’étape précédente. Au terme de chaque étape, il faut impérativement passer à la suivante. Une phase ne peut débuter que lorsque les résultats de la phase précédente sont confirmés. Le projet suit une direction précise, très structurée jusqu’à son objectif final. Le terme Waterfall réfère à l’idée que, telle l’eau qui descend d’une cascade ne peut pas remonter, il est quasi impossible pour l’équipe projet de faire marche arrière, sauf si un problème majeur a été détecté lors de l’étape de vérification. L’équipe projet travaille seule, en respectant rigoureusement le cahier des charges défini lors de la phase initiale. Aucune intervention du client n’est prévue durant toute la durée du projet jusqu’à la phase de validation. Il faut donc éviter tout oubli lors de la première phase.

Encore aujourd’hui, le mode d’opération strict et rigoureux de la méthode en cascade convient parfaitement aux besoins de certaines entreprises. Cependant, bon nombre d’organisations s’orientent davantage vers une approche dynamique et placent le client au cœur de leurs actions pour le développement et la livraison de leurs produits. Dans un environnement où les clients ont de plus en plus recours aux transactions numériques, les développeurs jouent un rôle central dans l’expérience client.

C’est pour cette raison qu’à présent la méthode Agile est souvent préférée à la méthode Waterfall. Beaucoup plus souple, elle fait intervenir le client tout au long du projet. Cela dit, rien n’interdit de créer sa propre méthode en combinant la méthode Waterfall et la méthode Agile.

L’Agilité : pour répondre aux projets de transformation organisationnelle

La méthode Agile est caractérisée par la collaboration et la discussion. Contrairement à beaucoup d’autres méthodologies, elle accueille favorablement l’expérimentation et les échecs qui peuvent éventuellement en résulter. Elle favorise une logique test & learn, c’est-à-dire qu’une première version du produit est proposée, si elle fonctionne bien, on utilise le code tel qu’il est pensé initialement puis on perfectionne au fur et à mesure l’application de diverses fonctionnalités. Le principe de base de l’approche Agile repose sur la nécessité d’apprendre de ses expériences, positives ou négatives. Cette méthode met donc l’accent sur l’adaptabilité, l’amélioration continue et la réactivité aux changements grâce à une approche itérative qui permet de s’ajuster et de créer de la valeur. Le feedback est également un élément primordial dans ce type de gestion de projet informatique.

Historiquement, dans le domaine du développement de logiciel, les secteurs du développement et des opérations ont longtemps travaillé chacun de leur côté. Il existait une barrière très étanche entre les développeurs qui étaient chargés de l’écriture du code, les administrateurs système qui s’assuraient par la suite de son déploiement et de son intégration et les utilisateurs. La communication était limitée à sa plus simple expression, les professionnels de chaque secteur travaillant séparément sur un même projet. Chacun savait ce qu’il avait à faire et n’avait pas tendance à interagir avec les autres groupes. Si ce mode opératoire était approprié lorsque la méthode de développement en Cascade était prédominante, l’essor de l’approche Agile et du flux de travail continu imposaient un changement. L’approche DevOps est alors apparue comme la solution toute désignée pour faire face avantageusement à ce changement.

L’approche DevOps : la collaboration et la communication avant tout

Parmi les grands principes qui ont changé, il y a celui de la collaboration et de la communication. La tendance à l’Agilité a été une source d’inspiration pour DevOps dont l’un des éléments clés Agile met en avant les spécialistes et leurs interaction plutôt que les processus et les outils. DevOps est un ensemble de pratiques qui privilégient en effet la collaboration et la communication entre les développeurs de logiciels et les professionnels des opérations informatiques pour tout projet IT, en automatisant le processus de livraison des produits et les changements d’infrastructure. Le terme DevOps prend sa source de l’association du développement (dev) et des opérations (ops) et a pour objectif de concilier les deux équipes.

À l’instar de l’approche Agile, DevOps présente comme atout additionnel une hiérarchie horizontale, c’est-à-dire que chaque membre de l’équipe prend en charge la gestion de son périmètre et de ses responsabilités de manière totalement autonome. Si mettre en place ses processus DevOps implique une vraie transformation, les décisions se prennent sans hésitation, le pilotage est plus fluide tout autant que la livraison des produits.

On l’a vu, une foule d’d’évolutions mineures et majeures ont chamboulé la manière qu’ont les entreprises de mener leurs projets IT depuis une vingtaine d’années et ce, à plusieurs niveaux. Et qu’en est-il de la gestion de projets informatiques de demain en termes d’évolutions ? On peut prédire sans trop d’erreurs qu’elle ne sera pas plus figée que celle des dernières années. Parce que tout se transforme très rapidement (technologies, attentes des entreprises, attentes des clients…) les méthodologies et les outillages seront eux aussi différents. Il suffit de prendre le meilleur de chacun, en fonction des objectifs à atteindre.