Les méthodes Agile sont nées dans les années 1990, elles sont devenues populaires après la bulle internet, en réaction à la tendance alors dominante : la réduction des coûts par le recours massif à l’offshore, encore mal maîtrisé à cette époque, avec pour conséquence des projets en l’occurrence peu agiles.

Il existe de multiples définitions du paradigme Agile. Leur point commun est la priorité donnée au développement d’un logiciel qui fonctionne plutôt qu’à l’exhaustivité de la documentation et à l’adaptation au changement plutôt qu’au suivi d’un plan. Scrum (« mêlée » en français1), la méthodologie Agile la plus répandue, recommande :

• - Des «sprints» de 2 à 4 semaines, le résultat de chaque sprint pouvant être mis en production pour prendre en compte les retours d’expérience dans un sprint suivant. 

• - Un « product owner », capable d’apporter son expertise fonctionnelle et constituer un 
« backlog » de « user stories », liste dans laquelle on sélectionnera les fonctionnalités du prochain sprint en fonction des priorités métier et de la capacité de production de l’équipe.

- L’engagement des développeurs : ce sont eux qui s’engagent sur leurs estimations et la faisabilité d’un sprint, et pas un chef de projet, qui n’existe d’ailleurs pas : ni le product owner, ni le « scrum master », l’orchestrateur du processus Agile, ne sont des chefs de projet.

- Le TDD (Test Driven Dévelopment) : les tests sont automatiques et développés avant les fonctionnalités proprement dites.

L’objectif est de supprimer toutes les tâches non indispensables à la réalisation d’une application utilisable. En cela, l’Agile se rapproche du Lean de l’industrie automobile des années 1980. L’Agile emprunte d’ailleurs à Lean beaucoup de ses rituels : les « cérémonies » Agile (les réunions cadençant l’avancement des développements) se déroulent selon un rythme soutenu, debout autour d’un Kanban.

Les outils de développement se sont adaptés à ces nouveaux processus, citons par exemple les outils d’intégration continue qui permettent de tester et générer un logiciel exécutable en continu, typiquement tous les jours.

Les avantages de l’Agile sont évidents : une mise en production (un « time to market ») plus rapide et un coût réduit grâce à la limitation des développements au strict nécessaire.

Ses inconvénients sont tout aussi réels : 
Les compétences : les membres de l’équipe Agile doivent maîtriser de nombreuses technologies et outils, et comprendre le besoin métier en profondeur. Ce sont des ressources rares (et chères). Le modèle Agile est par suite difficile à répliquer, à « scaler », dans l’organisation.

- Un projet Agile n’est pas compatible avec un cadre forfaitaire (un sprint entier peut être dédié à la refonte d’un sprint précédent suite aux retours du terrain, les contrats au forfait ne permettent guère de financer ces activités de refonte à fonctionnalités constantes). Les directions des achats ont du mal à accepter l’Agile du fait de cette impossibilité à forfaitiser.

- Certaines technologies et activités (les ERP, la maintenance avec un flot quotidien de « tickets » à traiter dans les 48h) sont difficiles, quoique non impossibles, à traiter en Agile.

Au-delà de ces difficultés, l’Agile doit également faire face à deux défis majeurs :

• - L’Agile à l’échelle (« scaled 
agile ») : l’Agile est adapté aux petites équipes (moins de 10 personnes), la situation se complique dans un programme où plusieurs équipes agiles doivent collaborer. Il faut alors passer à des méthodologies plus sophistiquées (« scaled agile framework » tels que SAFe) qui constituent un véritable challenge pour les équipes. En pratique, les équipes capables de maîtriser le scaled agile sont très peu nombreuses, même à l’échelle mondiale. 

• - L’Agile en mode distribué ; par construction, l’Agile requiert l’unité de lieu pour raccourcir la durée des échanges au sein de l’équipe. C’est a priori en contradiction avec les modèles de développement distribué qui sont la norme aujourd’hui (avec des équipes offshore notamment). Bien que moins complexe que le problème du scaled agile, l’Agile distribué requiert du soin et des outils adaptés. 
Le Devops est souvent vu comme la suite logique de l’Agile. Il consiste à fusionner au sein d’une même équipe les développeurs (dev), qui construisent l’application, et les administrateurs système qui la mettent en production et l’opèrent (ops). C’est un changement majeur : jusqu’à présent, les DSI étaient organisées en départements Etudes et Production, dans des mondes bien séparés, avec des profils bien différents (les geeks en basket dans le dev, les 
ingénieurs système dans les salles climatisées des datacentres pour l’ops).

Les méthodes Agile sont nées dans les années 1990, elles sont devenues populaires après la bulle internet, en réaction à la tendance alors dominante : la réduction des coûts par le recours massif à l’offshore, encore mal maîtrisé à cette époque, avec pour conséquence des projets en l’occurrence peu agiles.

Il existe de multiples définitions du paradigme Agile. Leur point commun est la priorité donnée au développement d’un logiciel qui fonctionne plutôt qu’à l’exhaustivité de la documentation et à l’adaptation au changement plutôt qu’au suivi d’un plan. Scrum (« mêlée » en français1), la méthodologie Agile la plus répandue, recommande :

• - Des «sprints» de 2 à 4 semaines, le résultat de chaque sprint pouvant être mis en production pour prendre en compte les retours d’expérience dans un sprint suivant. 

• - Un « product owner », capable d’apporter son expertise fonctionnelle et constituer un 
« backlog » de « user stories », liste dans laquelle on sélectionnera les fonctionnalités du prochain sprint en fonction des priorités métier et de la capacité de production de l’équipe.

- L’engagement des développeurs : ce sont eux qui s’engagent sur leurs estimations et la faisabilité d’un sprint, et pas un chef de projet, qui n’existe d’ailleurs pas : ni le product owner, ni le « scrum master », l’orchestrateur du processus Agile, ne sont des chefs de projet.

- Le TDD (Test Driven Dévelopment) : les tests sont automatiques et développés avant les fonctionnalités proprement dites.

L’objectif est de supprimer toutes les tâches non indispensables à la réalisation d’une application utilisable. En cela, l’Agile se rapproche du Lean de l’industrie automobile des années 1980. L’Agile emprunte d’ailleurs à Lean beaucoup de ses rituels : les « cérémonies » Agile (les réunions cadençant l’avancement des développements) se déroulent selon un rythme soutenu, debout autour d’un Kanban.

Les outils de développement se sont adaptés à ces nouveaux processus, citons par exemple les outils d’intégration continue qui permettent de tester et générer un logiciel exécutable en continu, typiquement tous les jours.

Les avantages de l’Agile sont évidents : une mise en production (un « time to market ») plus rapide et un coût réduit grâce à la limitation des développements au strict nécessaire.

Ses inconvénients sont tout aussi réels : 
Les compétences : les membres de l’équipe Agile doivent maîtriser de nombreuses technologies et outils, et comprendre le besoin métier en profondeur. Ce sont des ressources rares (et chères). Le modèle Agile est par suite difficile à répliquer, à « scaler », dans l’organisation.

- Un projet Agile n’est pas compatible avec un cadre forfaitaire (un sprint entier peut être dédié à la refonte d’un sprint précédent suite aux retours du terrain, les contrats au forfait ne permettent guère de financer ces activités de refonte à fonctionnalités constantes). Les directions des achats ont du mal à accepter l’Agile du fait de cette impossibilité à forfaitiser.

- Certaines technologies et activités (les ERP, la maintenance avec un flot quotidien de « tickets » à traiter dans les 48h) sont difficiles, quoique non impossibles, à traiter en Agile.

Au-delà de ces difficultés, l’Agile doit également faire face à deux défis majeurs :

• - L’Agile à l’échelle (« scaled 
agile ») : l’Agile est adapté aux petites équipes (moins de 10 personnes), la situation se complique dans un programme où plusieurs équipes agiles doivent collaborer. Il faut alors passer à des méthodologies plus sophistiquées (« scaled agile framework » tels que SAFe) qui constituent un véritable challenge pour les équipes. En pratique, les équipes capables de maîtriser le scaled agile sont très peu nombreuses, même à l’échelle mondiale. 

• - L’Agile en mode distribué ; par construction, l’Agile requiert l’unité de lieu pour raccourcir la durée des échanges au sein de l’équipe. C’est a priori en contradiction avec les modèles de développement distribué qui sont la norme aujourd’hui (avec des équipes offshore notamment). Bien que moins complexe que le problème du scaled agile, l’Agile distribué requiert du soin et des outils adaptés. 
Le Devops est souvent vu comme la suite logique de l’Agile. Il consiste à fusionner au sein d’une même équipe les développeurs (dev), qui construisent l’application, et les administrateurs système qui la mettent en production et l’opèrent (ops). C’est un changement majeur : jusqu’à présent, les DSI étaient organisées en départements Etudes et Production, dans des mondes bien séparés, avec des profils bien différents (les geeks en basket dans le dev, les 
ingénieurs système dans les salles climatisées des datacentres pour l’ops).

Dans le Devops, la mise en production devient une étape, la dernière, du développement. Très concrètement, il s’agit de développer (de coder) les scripts qui automatisent la mise en production, le déploiement, et l’administration des applications. On évite donc le passage de témoin entre études et production (qui occasionnait souvent des itérations improductives entre les deux camps) avec des avantages évidents sur le time to market et la capacité à faire évoluer l’application. C’est encore plus vrai si le Devops s’insère dans un cycle Agile ; certains projets effectuent ainsi plusieurs mises en production quotidiennes, chose jusqu’alors impensable.

Le Devops permet également des économies significatives dans les équipes de production et d’administration système. Leur ampleur est encore sous-estimée, les promoteurs du Devops mettant l’accent aujourd’hui d’abord sur le time to market.

Les limites de ce Devops si prometteur sont d’ordre technique : l’automatisation de la production requiert des configurations simples, sans opérations manuelles, inévitables dans les datacentres classiques du fait de l’hétérogénéité des environnements. En pratique, le devops ne peut être déployé simplement que dans le cloud. Les obstacles au devops sont donc les obstacles au cloud :

- La souveraineté des données : beaucoup d’entreprises et d’administrations n’acceptent pas de ne pas savoir où leurs données sont stockées, ni que l’opérateur du cloud puisse y avoir accès,

- Les ressources capables de d’automatiser les mises en production et concevoir des architectures adaptées au cloud ne sont pas légion. Le modèle est, ici encore, peu scalable.

- Certaines technologies s’accommodent mal du cloud (les « vieux » systèmes d’exploitation par exemple).

Pour toutes ces raisons et malgré l’effet de mode, le Devops (au contraire de l’Agile déjà largement répandu) reste encore confidentiel.

Time to market réduit, coût de possession optimisé, flexibilité acquise par construction...L’Agile et le Devops sont très supérieurs aux méthodes traditionnelles ; et ce sont de véritables révolutions pour les DSI, voire pour l’entreprise entière.

Les obstacles à leur généralisation tels que la rareté des ressources et les modes contractuels disparaissant graduellement, on peut faire le pari qu’ils deviendront rapidement la norme pour tous les nouveaux développements, tant leurs avantages sont évidents.

Il sera alors temps d’aborder l’étape suivante : la transition du mode projet au développement de produits. Les logiciels applicatifs (l’application mobile, big data, la fonctionnalité d’un site web) seront considérés comme des produits, avec des architectures capables d’évoluer rapidement. Les « roadmaps » seront définies par les équipes produit en fonction des objectifs métier et marketing qui leurs sont assignés et non plus par des directions métier soumettant leur besoin à une DSI. Ces modes de fonctionnement ont prouvé leur efficacité chez les « pure players » du web (Spotify est la référence dans ce domaine), nul doute qu’ils seront adoptés prochainement par les entreprises et les administrations.

Dans le Devops, la mise en production devient une étape, la dernière, du développement. Très concrètement, il s’agit de développer (de coder) les scripts qui automatisent la mise en production, le déploiement, et l’administration des applications. On évite donc le passage de témoin entre études et production (qui occasionnait souvent des itérations improductives entre les deux camps) avec des avantages évidents sur le time to market et la capacité à faire évoluer l’application. C’est encore plus vrai si le Devops s’insère dans un cycle Agile ; certains projets effectuent ainsi plusieurs mises en production quotidiennes, chose jusqu’alors impensable.

Le Devops permet également des économies significatives dans les équipes de production et d’administration système. Leur ampleur est encore sous-estimée, les promoteurs du Devops mettant l’accent aujourd’hui d’abord sur le time to market.

Les limites de ce Devops si prometteur sont d’ordre technique : l’automatisation de la production requiert des configurations simples, sans opérations manuelles, inévitables dans les datacentres classiques du fait de l’hétérogénéité des environnements. En pratique, le devops ne peut être déployé simplement que dans le cloud. Les obstacles au devops sont donc les obstacles au cloud :

- La souveraineté des données : beaucoup d’entreprises et d’administrations n’acceptent pas de ne pas savoir où leurs données sont stockées, ni que l’opérateur du cloud puisse y avoir accès,

- Les ressources capables de d’automatiser les mises en production et concevoir des architectures adaptées au cloud ne sont pas légion. Le modèle est, ici encore, peu scalable.

- Certaines technologies s’accommodent mal du cloud (les « vieux » systèmes d’exploitation par exemple).

Pour toutes ces raisons et malgré l’effet de mode, le Devops (au contraire de l’Agile déjà largement répandu) reste encore confidentiel.

Time to market réduit, coût de possession optimisé, flexibilité acquise par construction...L’Agile et le Devops sont très supérieurs aux méthodes traditionnelles ; et ce sont de véritables révolutions pour les DSI, voire pour l’entreprise entière.

Les obstacles à leur généralisation tels que la rareté des ressources et les modes contractuels disparaissant graduellement, on peut faire le pari qu’ils deviendront rapidement la norme pour tous les nouveaux développements, tant leurs avantages sont évidents.

Il sera alors temps d’aborder l’étape suivante : la transition du mode projet au développement de produits. Les logiciels applicatifs (l’application mobile, big data, la fonctionnalité d’un site web) seront considérés comme des produits, avec des architectures capables d’évoluer rapidement. Les « roadmaps » seront définies par les équipes produit en fonction des objectifs métier et marketing qui leurs sont assignés et non plus par des directions métier soumettant leur besoin à une DSI. Ces modes de fonctionnement ont prouvé leur efficacité chez les « pure players » du web (Spotify est la référence dans ce domaine), nul doute qu’ils seront adoptés prochainement par les entreprises et les administrations.