samedi 13 octobre 2012

BH-L’agilité comme moteur de changement-Julien Mathonnière


En suivant l’organisation des Jeux Olympiques de Londres, je fus consterné d’apprendre, comme beaucoup, que la société privée chargée de la sécurité s’avérait totalement incapable de remplir ses obligations, et qu’à moins d’un mois de l’ouverture, le gouvernement britannique se voyait contraint de faire appel aux armées. Dans l’éventualité d’une attaque terroriste sur une capitale sur-fréquentée et donc vulnérable, cette décision s’imposait.

Souvenez-vous que certains des militaires alors déployés dans Londres venaient de rentrer de missions difficiles et dangereuses en Afghanistan, une préparation pour le moins peu adaptée au maintien de la sécurité lors d’une des plus grandes célébrations de la planète. Et pourtant, ce fut un succès : visiteurs comme londoniens saluèrent le professionnalisme des forces armées, leur sens de l’humour et leur humanité.

Je vois au moins deux leçons à tirer de cette réussite. La première, c’est qu’une bonne entreprise doit être capable d’agir prestement et de s’adapter rapidement, ce en quoi les armées, lorsqu’elles sont bien entraînées, excellent généralement. La seconde, c’est qu’en faisant preuve d’autant de flexibilité et d’agilité, une telle entreprise contribue à susciter un sentiment de professionnalisme dans les rangs, ce qui lui confère une légitimité quasi instantanée, aussi bien auprès de ses clients (ou des populations qu’elle sert si c’est une armée) que de ses employés.

A Londres, les militaires britanniques ont démontré qu’être en mesure d’apporter des solutions créatives à des problèmes circonstanciels constituait un atout majeur. Même dans une structure aussi hiérarchique que l’armée, la diversité des parcours et des expériences individuels favorise l’émergence de cette créativité. L’inévitable corolaire, c’est que toute organisation devrait encourager et préserver cette diversité et non la lisser ou la formater d’une manière standard et prédéfinie, car elle se priverait alors de ce précieux bouillon de culture.

Il est curieux de constater que le recrutement des armées françaises favorise, plus que n’importe quelle autre entreprise, la diversité des candidats, en particulier chez les officiers de l’armée de terre où, en quelques années, il s’est ouvert à de multiples filières. En termes de culture d’entreprise, c’est un atout formidable que l’entraînement et la formation ne valorisent à aucun moment. Alors qu’ils devraient leur permettre d’imprimer leur marque et leur culture à l’organisation, ils imposent au contraire une assez forte uniformisation par le haut, au détriment, une fois encore, des idées nouvelles.

En s’adaptant à un environnement non combattant, sans précontrainte de formation, les régiments britanniques mobilisés à Londres ont fait preuve d’agilité, non pas au sens de temps de réponse à une menace ou une cible mouvante, mais comme capacité de s’adapter aux circonstances et de faire bien. Or, l’adaptabilité est au cœur des concepts « Agile ». Ce groupe de pratiques est le fruit d’une réflexion menée par quelques pionniers de l’industrie logicielle.

Il s’agit, à l’origine, d’une méthode de développement informatique impliquant au maximum le client, afin de réagir plus rapidement à ses demandes. Plus pragmatique que les méthodes de conception traditionnelles, elle a pour objectif la satisfaction réelle d’un besoin précis, et non d’un contrat établi préalablement. Elle repose sur un certain nombre de valeurs fondamentales qui sont autant d’incitations à l’innovation continue et par là même, à l’émergence d’idées nouvelles et constructives.

Elle pourrait être très utilement transposée aux armées, sans présenter de difficultés majeures.

Premièrement, parce que cette méthode ou cette philosophie privilégie les individus et les interactions plutôt que les processus ou les outils disponibles. Dans une perspective Agile, l’équipe est bien plus importante que les moyens matériels ou les procédures. Ainsi, il est préférable d’y fédérer un ensemble de talents moyens, mais qui communiquent efficacement entre eux, que de laisser quelques individus brillants mais trop individualistes prennent la direction du projet. Les NTIC permettent précisément cela, à moindre coût et sans grosse difficulté logistique.

C’est le modèle « Wikipédia » et vous ne serez probablement pas étonnés d’apprendre que l’un des fondateurs des pratiques Agile fut Howard Cunningham, l’inventeur du concept wiki de collaboration en ligne.

Ensuite, parce qu’il est impératif que le produit fonctionne. La documentation technique doit rester secondaire car elle représente une charge de travail importante, qui plus est néfaste lorsqu’elle n'est pas à jour. Dans cette optique, la consignation minutieuse des expériences accumulées dans tel ou tel théâtre d’opération (documentation, Retex) est, à mon sens, beaucoup moins important que l’émergence rapide de solutions fonctionnelles et immédiatement applicables sur le terrain.

Pour cela, il faut que l’utilisateur final – ici les officiers subalternes - soit impliqué dans le développement. Il doit collaborer et fournir un feed-back continu sur l'adaptation du produit à ses attentes. On ne peut plus se contenter de laisser les états-majors négocier un contrat au début du projet, puis de négliger ensuite les demandes d’adaptation ou de modification des utilisateurs sur le terrain. Lorsqu’une carence de la formation est constatée sur le terrain, elle doit faire l’objet d’une remontée vers le commandement et rapidement d’un correctif.

Sans cela, on ne ferait que reproduire bêtement les mécanismes de la programmation militaire, c’est-à-dire la spécification d’un besoin à un instant T qui, une fois le produit livré dix ou quinze plus tard, ne correspond plus à la réalité des engagements.

Le but est donc de produire, quatrième et dernier aspect, une solution qui satisfasse le client, et non qui respecte à la lettre la spécification fonctionnelle rédigée plusieurs années auparavant, lorsque les conditions ou les contraintes étaient différentes.  Il faut donc vérifier fréquemment que la direction prise soit celle qui mène à sa satisfaction effective. L’acceptation du changement doit l’emporter sur la conformité aux plans.

En outre, la méthode est dite « itérative », c’est-à-dire qu’elle fonctionne sur des cycles courts qui aboutissent chacun à la livraison d’une fonctionnalité supplémentaire. Chaque nouvelle brique du projet est ainsi livrée, installée et testée beaucoup plus rapidement que dans une méthode de développement conventionnel. Il est plus facile de changer d’orientation sur un projet quand chaque évolution coûte peu, et évite d’avoir à modifier des fonctionnalités qui ont déjà été développées.

L’ensemble de ces 4 valeurs fondamentales constitue le socle de ce que l’on appelle couramment une démarche Agile. Une armée n’est donc pas simplement agile parce qu’elle sait faire preuve d’initiative et de créativité dans une situation inattendue. Le terme décrit aussi la façon dont une organisation est capable de se réinventer lorsque les circonstances changent, à la manière d’un couteau suisse : on peut la configurer, l’adapter et l’utiliser dans une myriade de situations totalement différentes.

Par extension, le qualificatif peut être utilisé pour décrire une organisation capable d’adaptation évolutive, c’est-à-dire de se transformer pour rester compétitive ou pertinente dans un monde en mutation. C'est précisément cette capacité d'évolution qui reflète la forme supérieure de l'agilité.

C’est cet aspect que je trouve le plus intéressant, en particulier pour les armées, car l’organisation ne se contente plus de simplement s’adapter, mais d’évoluer en modifiant ses structures, ses processus, les rôles et les règles d'engagement pour qu'ils soient plus en phase avec l’environnement. Comme nous l’avons souligné, une armée bien entraînée sait parfaitement s’adapter, sur le principe du couteau suisse. Mais une armée douée d’une capacité d’évolution liée à son agilité possède un atout supplémentaire : la résilience. Elle reste pertinente malgré l'évolution des circonstances et maintient un haut niveau d'efficacité quand l'environnement change.

L’intérêt d’un tel courant de pensée, c’est qu’il introduit un nouveau paradigme en opposant l’empirisme pragmatique au rationalisme cartésien. Il préférera donc l’adaptabilité (le couteau suisse) à la prédictivité (le conflit le plus probable à l’horizon T est X à 80% et Y à 20%, donc nous allons consacrer 80% de notre formation à X et 20% à Y).

Du coup, le raisonnement, la pensée, la philosophie et la structuration de la méthode qui sous-tendent la formation des officiers pourraient emprunter de nouvelles voies. Des voies inédites pour des armées certainement très éprises de rationalité cartésienne mais qui, dans un contexte géopolitique en perpétuelle mutation, auraient fortement intérêt à encourager, de manière justement rationnelle, le sens de l’initiative de ses cadres. C’est en cela que les courants de pensée Agile me semblent prospères et féconds, car les plus à même de laisser s’épanouir une diversité et une créativité constructives, sources d’une culture d’entreprise dynamique, vivante et à forte valeur ajoutée, comme celles d’Apple ou de Google. Les armées pourraient s’en donner facilement les moyens, à faible coût, mais à la condition d’accepter un changement de culture. Est-ce un prix si élevé pour survivre et prospérer ?

Source Wikipedia

Rationalisme cartésien
Empirisme pragmatique
Paradigme
Prédictivité
Adaptabilité
Méthodes
Classiques ou « complètes »
Nouvelles ou « agiles »
Cycle projet
En cascade (sans rétroaction)
Incrémentiel et itératif (adaptatif)
Forme de levée du risque
Descriptive et documentaire
Recherche-action-expérimentation
Raisonnement
Discursif (prémisses-conclusions)
Systémique et heuristique
Vision sous-jacente
Isoler pour structurer une partie d’univers figé
Exécuter pour comprendre la dynamique des interactions
Pensée
Réductionnisme et hypothèses mécanistes
Vision holistique des phénomènes (RH, communication, environnement)
Philosophie d’analyse
Considère la nature des interactions
Considère les effets des interactions
Structuration méthode
Sur la base figée de niveaux isolants d’abstractions et de préoccupations
Sur la base d’un phasage simple et souple prenant en compte les contraintes du projet
Conduit à des systèmes
A forte entropie
A forte rétroactivité, cybernétique
Aboutissement
Recherche d’exhaustivité de la solution
Accepte un « rendement satisfaisant »
Philosophie d’action
Conduit à une action totalement programmée et détaillée
Conduit à une action flexible et pilotée par objectifs
Validation par
Test de chaque élément sur jeux d’essais ou copie de la réalité
Confrontation permanente du modèle avec la réalité

3 commentaires:

  1. Bonjour,
    Article intéressant, mais il semble y avoir confusion entre le principe des "briques" (dans des développements comme PHPNuke par ex) et la méthodologie Agile, les 2 n'ayant en fin de compte aucun lien. Le système de briques logiciels a commence à être mis en place dans les années 80, avec les drivers d'imprimante. L'idée est de déterminer une norme de communication entre modules, ce qui permet à des développeurs séparés de faire chacun leurs modules, les liens étant réalisés à l'utilisation: j'achète une imprimante, j'installe le driver et celui-ci est pris en compte par mon système, alors même que celui-ci a été réalisé avant le driver. Le projet le plus aboutit dans ce domaine est sans doute celui d'Open Doc de chez Apple, http://en.wikipedia.org/wiki/OpenDoc. Le projet n'a jamais été terminé, mais représentait une manière de voir totalement modulaire.
    Le 2éme point concerne les "itérations". L'article présente celles-ci comme si la fourniture de modules donc de ces briques constituait ces itérations. Or, en développement, lorsque l'on parle des itérations, on parle du processus d'élaboration donc on parle des itérations DANS la conception d'une brique et pas des briques elles-mêmes ni des fonctionnalités.
    Si on peut concevoir un fonctionnement militaire "par briques", encore faut-il considérer que les "briques" doivent parfaitement communiquer entre-elle. A la moindre "friction", plus rien ne fonctionne (voir l'enfer du débuggage de PHPNUke ou de Joomla par ex!)
    Quant aux itérations, soyons clairs: quelque soit le mode de développement, il existe des itérations. Mais elles ne se font pas dans le même axe... d'où la confusion.
    Il existe 2 manières de faire un développement: séquentiel ou incrémental. Le plus simple comme exemple, c'est la réalisation d'un Power Point.
    Solution séquentielle: je fais ma 1ère diapo, avec titre, images, textes, animations etc... puis je fais la 2éme diapo, puis la 3éme... Chaque diapo étant une séquence compléte. Avantage: je peux rapidement montrer une diapo finie. Inconvénient: les choix que j'ai fait sur la diapo 1, bride ma diapo 2 a qui je vais donc "tordre le cou" pour qu'elle soit "dans le même esprit" que la 1. Le problème va s'accroitre avec la diapo 3, puis la 4 et en fin de compte, ce qui semblait bien commencer va s'enliser. Lorsque je donnais des cours en IUT, je disais aux étudiants que cela ressemblait à la course sur la plage: on commence dans la sable sec donc on va pas vite (phase de préparation) puis on arrive sur le sable humide et là, ça fonce! Mais plus on va entrer dans l'eau, plus ça va être difficile. On a donc un fort risque d'enlisement des développements.
    La 2éme solution, c'est la méthode incrémentale: je met grosso modo les titres sur TOUTES mes diapo, puis je met grosso modo les textes sur TOUTES les diapo, les ébauches d'image etc... Je travaille donc pas itération de "couches". Avantage: je peux retoucher les éléments sans risque de tout perturber. En cela, seul ce mode de développement se trouve bien adapté à l'Agilité. Inconvénient: impression d'un immense chantier dans lequel rien n'est terminé.
    Pour le développement type NTIC, nous avions opté pour cette démarche dès 1999. Ce rapport de stage http://www.flashover.fr/perso/Rapport_stage_PARX.pdf donne un bon aperçu de la méthodologie.
    Pour une application militaire, cela me semble possible hors du terrain. Mais sur le terrain, c'est un peu difficile à imaginer. On peut sans doute dire que le concept de Centre de Gravité "à l'Américaine" serait un mode de développement basique avec cahier des charges stricts donc "non Agile" et que le concept d'Effet Majeur est quand à lui plus proche de l'Agilité.

    RépondreSupprimer
  2. Bonjour,

    Et merci pour vos précisions. Pardon si j'ai pu manquer de clarté. En utilisant le terme de "brique", je ne pensais absolument pas au système des briques dont vous parlez et dont, pour être franc, j'ignore presque tout. Concernant les itérations ou incrémentations propres aux méthodes Agile, je les conçois bien, comme vous l'avez souligné, comme parties intégrantes de chacun des cycles ou processus d'élaboration, dont l'aboutissement sera un élément supplémentaire du projet (ce que j'ai maladroitement appelé "brique") ou, pour reprendre votre exemple, un morceau de contenu PowerPoint en plus.

    Ce que j'ai surtout voulu souligner, c'est la façon dont l'initiative et l'innovation sont FACILITEES dans le cadre de démarches Agile qui, sans être nécessairement appliquées à la lettre, ont d'ores et déjà profondément marqué la culture d'entreprise des leaders de l'industrie électronique. A la rigueur, les détails de la méthode importent moins que la philosophie empirique et pragmatique sur laquelle elle repose, à savoir des interactions fortes et très dynamiques entre tous les protagonistes d'un projet, et une flexibilité/adaptabilité absolues au prix parfois, comme vous le rappelez, d'une impression de chantier permanent.

    Assurément, la méthode n'est pas sans défauts. Mais il s'agit en premier lieu de valoriser le patrimoine immatériel d'une organisation et ce, en donnant à ses membres la possibilité d'exprimer leur créativité de manière constructive. De ce point de vue, je trouve que les pratiques Agile offrent des pistes très intéressantes aux armées.

    RépondreSupprimer
  3. Je rebondirais sur l'article et nos commentaires, sur un point qui n'apparait pas très souvent dans les articles de ce blog ou d'autres.

    Pour comprendre mon propos, je suis sapeur-pompier en charge de la mise en place de services de secours volontaires, au Brésil et entre autre de l'ensemble de la formation du personnel. Or, plus je cherche et plus je constate que chez les SP, il n'y a pas de doctrine (ce truc dont Foch disait que c'est "une manière commune de voir les choses"). On a donc plein de gens qui pensent penser la même chose alors qu'en creusant un peu, on voit que c'est faux. Mais surtout, on a chez les SP, des méthodes de raisonnement qui sont adaptées aux grands événements: la raffinerie qui brûle ou 10.000 hectares de forêt en feu. A ce stade, c'est le Cmd, le Ltn-Co ou le Colon qui gèrent.
    Mais quand un quartier part en fumée ou même toute une usine, ce n'est pas "d'un coup". ça commence toujours tout petit. Une analyse des moyens montre que le premier engin sur les lieux, avec un Sgt, un conducteur et 4 gars, a TOUT pour tuer le feu. Si on en arrive à ce que toute l'usine parte en fumée, c'est dans 9 cas sur 10 suite à l'échec de la première action. Or, on a beau chercher, des concepts tactiques souple, en phase avec un niveau aussi bas, on en trouve pas beaucoup...
    Si on regarde les conflits militaires actuels, ça commence à ressembler bigrement au cas de mon Sgt qui se pointe tout seul avec son camion devant la maison qui fume: le gars qui se retrouve avec ses 4 ou 5 collègues sous le feu de 5 ou 6 Talibans, n'a pas franchement le temps d'attendre la fin de la pause café au SHAPE...

    Peut-être qu'à ce niveau les méthodes AGILES seraient une piste car elles permettent de réagir rapidement et efficacement. Donc pas au niveau "haut", mais plutôt au niveau du terrain, pour une réaction rapide, en quelques minutes.
    Car si on a échec au niveau de ce petit groupe, on se retrouve vite dans l'obligation de déployer des moyens très importants.

    A noter, pour des recherches là dessus, une piste intéressante: "Le combat des petites unités" par le Colonel GERIN. C'est "vieux", mais ça reste bigrement d'actualité.

    Pour ce qui est de faciliter l'initiative, je suis 100% d'accord. Mais encore faut-il que dés la première formation, on mette l'accent sur cette possibilité que l'on offre. Car dans pas mal de cas, les organisations type "militaire" sont vues comme des systèmes dans lesquels on ne prend pas d'initiative. Là encore, peut-être un problème de doctrine: si je rentre en pensant qu'on va tout me dire et que je ne vais pas réfléchir, il est clair que je ne vais jamais être dans l'état d'esprit "initiative - innovation".
    Le problème n'est d'ailleurs pas récent:
    "Les seules fautes qui méritent des reproches sont l'inaction et la crainte des responsabilités". GQG 3éme Bureau, Manuel du chef de section d'infanterie Imprimerie Nationale 1918, page 18

    RépondreSupprimer