L’agilité figure parmi les termes « à la mode » dans le microcosme de l’informatique, et ce terme est décliné à tout propos. Tout un chacun revendique l’agilité, surtout dans le contexte actuel, où le roseau de La Fontaine sait se plier aux intempéries, en attendant des jours meilleurs.
On pourrait confiner cette requête d’agilité au domaine du développement de logiciel. Cependant, le voeu d’agilité s’étend à toutes les visions informatiques, et à celles des systèmes d’information, des processus, des règles métier… Et pourquoi pas de l’entreprise elle-même, des organisations et de leurs composantes ? Par transition, et amalgame des problématiques, on en vient à l’entreprise agile, une entreprise d’un nouveau type qui serait première dans la course à la création de valeur…
L’agilité tous azimuts existe-t-elle ? Est-ce une pure création du marketing, un rêve, voire un leurre ? Il y a bien là une grande confusion. Pour en revenir à la simplicité d’une fable, le lièvre gagne-t-il forcément la course contre la tortue ? De quoi parle-t-on ?
Personne ne conteste les enjeux de l’agilité, surtout dans un contexte de crise. Mais de quelles agilités parle-t-on, et sont-elles face aux mêmes enjeux ? 

Les multiples agilités informatiques

Les solutions informatiques ont constamment dégagé des degrés de liberté. En effet, l’extension des fonctions a toujours créé une complexité qui ne serait pas maîtrisable sans une rationalisation des composants via des standards, communs et partageables : création de routines système, de gestion d’entrées-sorties, puis de bases de données, protocoles de communication, balisages normalisés…

L’ingénuité des solutions informatiques a ainsi facilité, progressivement, de multiples flexibilités. Et en particulier, avec les générations successives d’architecture. Pourtant, réaliser des développements a toujours été un processus lent, complexe, et souvent mal abouti. Un des défis de l’agilité informatique vise à raccourcir les délais classiques d’un projet.

Les développements agiles

Les écueils des petits et grands projets se succèdent avec leur effet tunnel, le taux d’échec, le gâchis de code finalement inutilisé, les incompréhensions entre le métier et l’IT… Le fameux cycle « en cascade » a été remis en cause par des méthodes « agiles », créant des cycles plus courts et incrémentaux pour produire et intégrer les composants logiciels.

Les méthodes agiles visent à apporter plus tôt de la valeur en associant les utilisateurs aux livraisons successives. Elles tendent à éliminer les travaux sans apport de valeur, comme la formalisation de spécifications, la documentation (« Logiciel fonctionnel plutôt que documentation complète »), insistant sur la cohésion de l’équipe plutôt que sur la procédure, sur la collaboration avec le client plutôt que sur le contrat, et en acceptant le changement tout au long du projet.

Entre le jusqu’au-boutisme du développement agile, et la lourdeur et la faible maîtrise des risques toujours constatée dans les approches traditionnelles, il est sans doute possible de capitaliser sur les bons aspects de ces cultures de projet opposées.

Les alternatives au développement d’applications : ERP et plateformes d’applications agiles

Curieux de parler d’ERP quand il est question d’agilité ?… Certes, la complexité des ERP a souvent généré des rigidités, et l’agilité n’a pas été leur meilleur atout. Cependant, ils restent incontournables. D’ailleurs, même si tout change, les évolutions des fonctions support, moins agitées par les frictions concurrentielles, se sont accommodées des contraintes de ces mastodontes. Elles y ont même apporté la sécurité de la conformité réglementaire : l’entreprise a aussi besoin de rigidités pour garantir qu’il n’y a pas de prise de risque et d’initiatives déviantes. En somme, les ERP ont longtemps présenté la seule
alternative au développement.

Une troisième voie apparait maintenant mature, avec les plateformes d’applications agiles : suites BPM, de workflow, moteurs de règles, interfaces de présentation, gestion de documents. Sans oublier la problématique classique de gestion des données de référence, maintenant facilitée par les outils de MDM. Ces plateformes offrent des solutions génériques, a priori utilisables dans de nombreux contextes métier, et présentant un double avantage :

• limiter l’intervention de développeurs, en confiant d’ailleurs une bonne partie du paramétrage du coté de la maîtrise d’ouvrage
• faciliter au maximum les évolutions de processus, de règles, d’interface utilisateur, de documents, et désimbriquer les données de référence, par des actions ciblées sur ces seules composantes, nettement isolées et gérées en tant que telles.

Ces plateformes d’agilité amènent naturellement aux enjeux d’architecture. 

Fédérer les agilités : les architectures agiles et SOA

On voit bien que l’agilité ne se réduit pas au développement agile, car Il ne suffit pas de réaliser « vite et bien » le code élémentaire.
En effet, l’enjeu est surtout de pouvoir composer et recomposer ces éléments pour gérer les partages fonctionnels, maîtriser les évolutions, limiter les big-bangs et autres projets glorieux, mais hasardeux.

On peut dès lors souhaiter concevoir une architecture agile, en fournissant un cadre méthodologique et conceptuel aux développements et aux intégrations. C’est l’ambition des approches prônées par l’Institut Praxeme, ou par le CEISAR (Center of Excellence in Enterprise Architecture – Ecole Centrale Paris). Outre la méthode, il est aussi question de conception et d’architecture, avec l’ambition de modéliser l’entreprise. Car un mouvement de fond lent, mais à terme incontournable fait émerger les « architectures orientées services » : la fédération des offres des éditeurs autour de SOA traverse toute la planète informatique, et constitue l’aboutissement de l’État de l’Art technologique. Par nature, l’architecture orientée Services (SOA) est flexible :

• Facilité d’évolution des composants que sont les services, sans impact fort sur les autres services : principe d’intégration « lâche »,
• Orchestration des services nettement identifiée et externe,
• Interfonctionnement avec diverses technologies, et avec le patrimoine existant, facilitant la migration et la coexistence.

La flexibilité provient, non seulement de l’architecture, mais aussi de ses ouvertures. De monolithique et rigide, la solution devient alors évolutive par sa modularité, et par sa pratique de multiples environnements et logiciels. De plus, les acteurs humains se trouvent progressivement et logiquement en interaction, par divers canaux de workflow, de GED , et autres collaboratifs, avec l’orchestration de ces services.