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.
Des agilités informatiques à l’agilité du SI
Par delà le codage et la syntaxe : la finalité « métier »
La plus belle machine-outil ne produit pas nécessairement l’appareil qui convient à l’industriel pour son process de fabrication. Car l’outil est à la main de l’ouvrier qui forge le produit final. De même, le système d’information ne se réduit pas à la syntaxe de codage des informations, des logiciels, des échanges et invocations de services. Ni même à la conception d’une architecture parfaite.
Le système d’information permet le partage, la capitalisation, l’échange de connaissances qui ont du sens pour les acteurs de l’entreprise comme pour ses clients et partenaires. L’agilité du système informatique conduit certes à l’agilité du SI , cependant celle-ci nous interroge à un autre niveau, car il ne suffit pas de faire évoluer rapidement l’outil informatique. Encore faut-il être en mesure de le déployer rapidement, de migrer, d’adjoindre les facilités (processus, gestion des connaissances, ergonomie…), et de conduire le changement pour arriver au véritable résultat : un système opérationnel, y compris dans son appropriation par ses utilisateurs, voire par les clients et partenaires. Dans la chaîne d’agilité, l’agilité du changement est souvent le maillon faible.
Les déclinaisons de l’agilité du SI
La fonction informatique, dans toutes ses dimensions, gagne en flexibilité, et en réactivité. Par delà, la fonction système d’information est en cause, et mature pour accélérer son adaptation aux besoins métiers, aux exigences de marché, à l’alignement stratégique. Somme toute, l’agilité favorise l’accélération des cycles : cycle informatique et cycle associé à l’ensemble du système technique et des acteurs qui l’animent et l’accompagnent.
On a l’habitude de distinguer 3 temps dans les cycles informatiques : le « design time », le « run time », et « change time ». Dans le même ordre d’idée, le modèle CEISAR distingue Transformation et Opération. L’accélération de l’opération est de l’ordre de la réactivité et celle de la transformation de l’agilité.
La diversité de ces cycles fondamentaux explique la diversité des axes d’agilité.
Tous ces cycles peuvent être accélérés ! L’enjeu majeur se porte sur les cycles placés du Nord au Sud-Est dans le schéma. Détail des cycles en amont :
- Cycle stratégique de l’entreprise : le sujet traite de l’alignement stratégique, ou de la synchronisation à la stratégie. Telle ou telle amélioration des délais peut être, à un moment donné, stratégique (délai d’adaptation à une nouvelle réglementation impactant un patrimoine applicatif, etc.). Gagner en agilité revient à améliorer la synchronisation stratégique, et nécessite des remises en cause d’un autre ordre. Question traitée ci-après.
- Cycle de parcours des besoins : en amont des projets, prendre en compte les besoins des différents métiers, et les besoins transverses, les arbitrer, en gérer le portefeuille, et valider les capacités à faire, avant d’initier les projets. On peut accélérer ces process par un arbitrage agile, et se doter d’outils pour optimiser cette activité cruciale pour l’adéquation de la fonction SI aux finalités de ses clients.
Agilité et anticipation : l’urbanisme des SI
Accélérer ou dépasser les rigidités ?
Comme illustré par le polygone précédent, l’agilité se résumet- elle simplement à la réduction de divers temps de cycle ? Certes, les améliorations tendancielles permettent de réduire la durée des projets, de déployer plus vite, de prototyper, de modifier les architectures…
Des évolutions d’un autre ordre sont à considérer : donner de la flexibilité là où toute évolution était tout simplement impossible dans une échelle de temps praticable et conforme au besoin, ou pour un coût compatible avec l’espoir de gain.
Ce type de flexibilité fondamentale est d’un autre ordre que l’agilité d’accélération : elle est en rupture. Elle existe ou non. En revanche, on ne l’obtient pas par amélioration tendancielle, il faut l’anticiper.
Ce constat vaut dans tous les domaines techniques où l’on identifie clairement des générations de systèmes. Les évolutions des offres d’architecture en sont une illustration limpide. Par exemple, la substitution d’un moteur de règles aux fonctions de conformité réglementaire d’un ERP ne s’improvise pas. Par contre, le jour où un tel outil est mis en place au coeur du moteur réglementaire, les adaptations deviennent aisées. Ainsi, une rupture bien anticipée reporte l’évolution en impact sur le « change time » et non sur le « design time ».
Anticiper la flexibilité
L’urbanisme a pour objectif d’apporter la flexibilité voulue, anticipée, et pertinente face aux besoins métier. Il ne s’agit plus simplement d’accélérer une mécanique préexistante, mais de trouver les ruptures qui rendent possible ce qui ne l’était pas ! La question ne consiste pas à se doter d’une architecture générique flexible, car le développement agile ou l’architecture parfaite ne conduisent pas nécessairement à l’entreprise agile. En pratique, la déformation ne peut être que progressive. Et, dans un monde très complexe, il est impossible de se doter d’une flexibilité tous azimuts.
Au-delà du SI, l’agilité de l’entreprise
L’agilité systémique
L’entreprise agile ne se réduit pas au SI agile… Avec le SI le mieux construit, même si tout est mis en oeuvre pour que les utilisateurs soient aussi agiles que le SI , accompagnant le changement sans délai, n’introduisant aucune viscosité au système, l’entreprise reste dépendante de son organisation, de sa culture… Selon cette organisation d’entreprise, cette culture maison ou l’histoire, le résultat sera totalement différent. Car les variantes organisationnelles, le degré d’autonomie, la subsidiarité reconnue et optimisée, le pragmatisme… bref, les divers facteurs sociaux sont déterminants pour l’agilité. D’ailleurs, la vision d’urbanisme systémique reconnaît ne pouvoir tout enfermer dans des schémas et tout maîtriser jusqu’au détail.
Ce principe peut être appliqué en dehors de la stricte sphère du SI , et dans la gouvernance même de l’entreprise, qui consacre cette vision systémique, et détermine l’agilité.
Les agilités stratégiques
Dans le contexte des usages présentés, l’agilité consiste à doper le SI, à l’accélérer, et le rendre plus flexible dans sa réponse aux sollicitations métier. Car le SI, moteur des opérations, coeur de l’usine à produire les services, freine le changement.
Pourtant, le discours est de prôner la rapidité dans le « time to market », clé dans l’économie développée. Il s’agit donc d’innover et de prendre de vitesse les concurrents. Doit-on pour cela être agile sur toutes dimensions du SI ? Et n’est-on pas, plus prosaïquement, embarrassé dans des activités de recherche et développement parfois peu ou pas informatisées ?
Les acronymes basés sur les 2 lettres, A pour assisté et O pour Ordinateur, ne sont plus de mise (CAO ? DAO ? GMAO ?), il serait pourtant bien utile de constater le développement d’AAO : agilité assistée par ordinateur.
Précipitation vs anticipation : le lièvre et la tortue
Confond-on vitesse et précipitation ? Que faut-il accélérer ? Est-ce simplement, dans la vision court terme, réaliser pour aujourd’hui ce qu’il fallait pour hier ? Les métiers sont-ils secoués par cette perpétuelle agitation, comme on se complait à le dire ? Au contraire ne constate-t-on pas une grande stabilité, fondée sur des invariants qui sont les sous-jacents de la fébrilité ? L’agilité est multiforme, et les amalgames masquent les pistes. Lesquelles mènent droit au but ? Le lièvre peut s’y perdre, et la tortue, anticipant à temps et à propos, gagner la course économique.
jeu, 02/04/2009 - 11:30 | 
adminitexpert
