1

SQLI
DIGITAL PERFORMANCE

TABLE DES MATIÈRES

1.​LE MANAGEMENT À L’ÉPREUVE DE L’AGILITÉ​................................................................................5-10
LE BESOIN DE CAUSALITÉ​
LA PEUR DE PERDRE SES RESPONSABILITÉS​
REDÉFINIR LES RÔLES DU MANAGEMENT​

2.​AGILITÉ ET COMPLEXITÉ​...............................................................................................................11-17
LA SYSTÉMIQUE​
LA CYBERNÉTIQUE​
LA THÉORIE DES SYSTÈMES DYNAMIQUES ET LE CHAOS​
LES AUTOMATES CELLULAIRES ET LES SYSTÈMES ADAPTATIFS​

3.​FAVORISER LA COMPÉTENCE ET L’AUTONOMIE​..........................................................................18-24

LES DANGERS CACHÉS DES « BONNES PRATIQUES »​
UNE DÉFINITION DE LA COMPÉTENCE​
LES DIFFÉRENTS TYPES DE MOTIVATION​
POURQUOI L’AUTONOMIE ?​

4.​FAVORISER L’AUTO-ORGANISATION DES ÉQUIPES​.....................................................................25-34

L’AUTO-ORGANISATION N’EST PAS UNE « BONNE PRATIQUE » !​
CRÉER LA CONFIANCE​
QUELS BUTS, POUR QUI ?
ENTRETENIR LA DIVERSITÉ​
FAVORISER LA CRÉATIVITÉ​
FAIRE ÉMERGER UNE VISION GLOBALE​

5.​DÉFINIR LES BONNES CONTRAINTES POUR CRÉER DE LA VALEUR​........................................35-39

COMMENT DÉFINIR DES RÈGLES​
ETABLIR UN CONTRAT SOCIAL​
DÉFINIR UN OBJECTIF PARTAGÉ​

6.​CRÉER LES CONDITIONS DE L’AMÉLIORATION CONTINUE​.........................................................40-44

CHANGER CAR L’ENVIRONNEMENT CHANGE​
L’ART DE LA NAVIGATION EN TERRAIN MOUVANT​

7.​CONCLUSION​.........................................................................................................................................45

8.RÉFÉRENCES.........................................................................................................................................46

3 48
 SQLI
DIGITAL PERFORMANCE

Pirmin Lemberger
avec la participation de
Houda Berrada,
Julie Lemaire et Arnaud Gonzales
13/09/2013

En dépit des succès engrangés ces dernières années par les démarches agiles, beaucoup
d’entreprises hésitent encore à les adopter, surtout en France. Ces réticences sont largement
à mettre au compte, pensons-nous, de démarches projets et d’organisations des tâches qui
pêchent par un excès de cartésianisme et ne prennent en compte, ni la complexité humaine,
ni la complexité technique des projets informatiques. Dans une industrie mouvante comme
l’informatique, où la connaissance, l’innovation et la créativité sont maîtresses, il convient de
redéfinir le rôle des managers pour que ceux-ci aident leurs équipes à être performantes dans
un monde incertain. Le point de vue développé dans ce livre blanc, inspiré des sciences de la
complexité, est qu’une équipe agile est un système social complexe et adaptatif qu’il s’agit
de faire prospérer. Les sciences de la complexité offrent pour cette tâche un large éventail
de métaphores que nous présenterons et qui permettent d’attribuer de nouveaux rôles au
management dans un contexte agile. Nous nous inspirons des idées développées par Jurgen
Appelo dans son livre « Management 3.0 ».

Ce livre blanc peut se lire comme une introduction à son analyse où l’adaptabilité remplace la
prédictibilité au rang de valeur cardinale.

4 48
SQLI
DIGITAL PERFORMANCE

LE MANAGEMENT À
L’ÉPREUVE DE L’AGILITÉ
Pour beaucoup d’entreprises soumises conjointement aux fluctuations des usages
numériques, aux mutations technologiques et à la nécessité de réduire les coûts de leurs
développements informatiques, les démarches dîtes agiles apportent aujourd’hui comme
une brise d’espoir, celui de voir se réaliser enfin le Graal de l’informatique : construire
des systèmes informatiques qui répondent aux besoins, tout en respectant les contraintes
de budget et de délais. Tous les types d’organisations sont a priori concernés, les DSI de
grandes entreprises, les ESN et même les éditeurs de logiciels ou les startups.

Si l’on omet les querelles de chapelle entre méthodologues, toutes ces démarches préconisent,
peu ou prou, la même stratégie :

• la réalisation sur un mode itératif de logiciels par des équipes auto-organisées à taille
humaine et ceci sans conception exhaustive préalable,
• des équipes techniques travaillant en collaboration étroite avec des utilisateurs chargés de
tester les fonctionnalités dès qu’elles sont disponibles.

On oppose d’ordinaire ces démarches agiles aux approches plus traditionnelles, comme le
L’un des premiers objectifs cycle en V, qui enchaînent les phases de recueil exhaustif des besoins, de spécifications, de
de ce livre blanc sera de conception, de développement, de tests et enfin de livraison. Le constat fondamental est bien
comprendre l’origine profonde connu : dans un environnement plus incertain que jamais, les spécifications, quel que soit le
des réticences vis-à-vis des soin qu’on mette à leur élaboration, s’avèrent trop souvent obsolètes avant même la première
démarches agiles. livraison du système aux utilisateurs.

Force est de constater toutefois, qu’en dépit des nombreux succès engrangés par ces démarches
(Mentor), des réticences tenaces subsistent et empêchent leur généralisation. A l’évidence,
la mise en avant des succès engrangés « ailleurs » n’est pas de nature à convaincre tous les
responsables informatiques : « ça ne marchera jamais chez nous ! » entend-on dire.

Plus important que le crédit que nous pourrions accorder à tel ou tel témoignage de succès et
la promotion que nous pourrions en faire, nous paraît l’élaboration d’une compréhension sur un
plan scientifique et psychologique de ce qui fait l’efficacité de ces démarches. Pour cela nous
nous appuierons largement sur le travail de pionnier de Jurgen Appelo décrit dans son ouvrage
« Management 3.0 » (Appelo, 2010)1 ainsi que sur les expériences de projets menés chez
SQLI. Dans cette perspective : l’un des premiers objectifs de ce livre blanc sera de comprendre
l’origine profonde des réticences vis-à-vis des démarches agiles.

1
Pour approfondir le sujet, nous recommandons vivement la lecture de cet ouvrage qui, par son originalité et la profondeur de ses
vues, se démarque largement de la prose insipide qui domine la littérature managériale contemporaine et cela, même si le foisonne-
ment d’idées qu’il contient n’en fait pas forcément une lecture facile. Jurgen Appelo est l’auteur de l’expression « Management 3.0 ».

5 48
SQLI
DIGITAL PERFORMANCE

Avant d’en arriver là, remarquons encore que l’engouement relatif pour les démarches agiles
n’est que relativement récent en France. Selon nos estimations il remonte à 3 ou 4 ans tout
au plus, la crise économique ayant pour le coup joué le rôle de catalyseur de l’innovation
méthodologique. Les prémisses conceptuelles de ces démarches sont, quant à elles, beaucoup
plus anciennes et remontent pour certaines à plus d’une vingtaine d’années (Nonaka, 1986.
Les démarches agiles proprement dites, formulées généralement sous forme des recueils de
bonnes pratiques ou de manifestes de valeurs, sont apparues pour la plupart au tournant du
siècle1.

Au plus proche de la technique, les développeurs et les architectes logiciels ont assurément
Comprendre l’origine été les premiers à saisir le potentiel des démarches agiles. Pour les réticences, c’est donc
psychologique de cette ailleurs qu’il faut regarder ! Vers les managers, compris au sens large comme tout responsable,
résistance, puis apporter hors direction générale. Voilà le cœur de notre sujet. Avant de l’aborder, énumérons rapidement
des réponses concrètes et quelques-uns parmi les faux arguments couramment invoqués pour faire obstruction aux
scientifiquement étayées aux démarches agiles :
rôles que devront assumer les
managers dans un contexte 1. l’agilité n’est qu’un déguisement du bricolage et du dilettantisme qui empêche l’émergence
agile constituent le fil rouge d’une rigueur élémentaire,
de ce livre blanc. 2. l’agilité ne permet aucune planification, empêche toute prédictibilité et l’élaboration d’une
documentation complète d’un système,
3. l’agilité ne s’applique pas aux grandes organisations,
4. la culture de l’organisation ne s’y prête pas,
5. l’agilité fait perdre le contrôle des équipes par les managers.

Quiconque a participé à un projet agile partagera l’avis que chacun de ces arguments relève
soit de l’idée fausse, tout simplement, soit de la peur séculaire du changement. Le point 1 par
exemple, fournit une bonne illustration d’une idée fausse à l’état pur puisque, chaque « agiliste »
le sait ; compétence technique et rigueur sont en réalité des préalables indispensables à toutes
ces démarches. Loin de négliger l’excellence technique, elles l’exigent, nous y reviendrons en
détail au chapitre 3. La peur du changement et de la perte de contrôle de la part d’une partie du
management constitue en réalité le cœur de notre propos. Nous pensons en effet que, derrière
ces résistances, se cache notamment une appréhension sourde de nombreux managers qui
entrevoient mal quel rôle ils pourraient jouer dans l’encadrement d’équipes agiles dès lors
que celles-ci sont réputées auto-organisées. Du coup, vis-à-vis de l’instauration de démarches
agiles, le management, hélas, fait aujourd’hui trop souvent partie du problème plutôt que
de sa solution. Comprendre l’origine psychologique de cette résistance, puis apporter des
réponses concrètes et scientifiquement étayées aux rôles que devront assumer les managers
dans un contexte agile constituent le fil rouge de ce livre blanc.
Les deux prochaines sections abordent les deux facteurs de résistance sur lesquels nous
souhaitons mettre l’accent : le besoin de causalité et la peur de perdre ses responsabilités.

1
XP en 1999, Scrum en 2001, Kanban en 2003 et le Lean Software Development en 2003.

6 48
SQLI
DIGITAL PERFORMANCE

LE BESOIN DE CAUSALITÉ
Dans notre pays, champion toutes catégories du cartésianisme, l’un des passages obligés
d’une majorité de projets informatiques reste à ce jour l’élaboration patiente des fameuses
spécifications du système à construire : générales, détaillées, fonctionnelles puis
non-fonctionnelles pour ne rien oublier.

Pour conjurer les aléas d’un projet nous aimons édicter ces mini-constitutions dans l’espoir (ou
l’illusion plutôt) que leur seule force législative en garantira le bon déroulement.
Une belle constitution, voilà qui rassure ! Le retard au démarrage vis-à-vis des démarches
agiles en France que nous évoquions plus haut n’est en rien le fruit d’un hasard. C’est plutôt
une manifestation d’un trait culturel bien identifiable, celui de notre gargantuesque appétit
réglementaire.

Le rituel des « specs » n’est qu’un exemple parmi d’autres d’un besoin inné de prédictibilité
Nombre de rituels plus général, qui n’est propre ni à l’IT ni aux habitudes locales. On peut assez facilement tenter
et de superstitions, de rationaliser ce besoin en invoquant diverses contraintes économiques que chacun aura
liés ou non à des projets présentes à l’esprit. Nous pensons cependant que là n’est pas le fond de l’affaire. En réalité,
informatiques, y trouvent ce besoin de contrôle est profondément enraciné dans la psyché humaine, bien au-delà des
une explication rationnelle seules contraintes économiques contemporaines d’un projet IT. Instinctivement, nous pensons
(Appelo, 2010), (Brooks, 2009). qu’il est toujours possible d’identifier les bonnes causes qui conduiront aux effets souhaités.
En grossissant légèrement le trait, nous espérons que les bonnes « specs » conduiront au bon
système ! Ce désir immodéré du déterminisme possède des causes diverses dont l’analyse
exhaustive dépasserait largement le cadre de ces lignes. Trois d’entre elles nous semblent
pourtant mériter une brève considération pour mieux situer la suite de notre propos. La première
est d’ordre biologique, la seconde est liée à l’histoire de la science récente et la dernière est liée
à notre éducation.

Sur le versant biologique et inné, il y a fort à parier que nous aimions le déterminisme car
l’aptitude à en faire bon usage a garanti durant plusieurs centaines de millénaires la survie de
nos lointains ancêtres qui habitaient la savane. Leur chance de survie face à des prédateurs plus
puissants et plus rapides était largement tributaire de leur aptitude à associer des causes et
des effets : si les branches d’un fourré bougent, c’est qu’un lion s’y cache ! Du coup, la sélection
naturelle a favorisé jusqu’à l’excès notre désir d’explication causale. Nous aimons trouver des
causes même lorsque celles-ci n’existent pas. Nombre de rituels et de superstitions, liés ou non
à des projets informatiques, y trouvent une explication rationnelle (Appelo, 2010), (Brooks, 2009).

La seconde cause de notre confiance immodérée dans les vertus du déterminisme est plus
récente et relève cette fois de l’acquis. Depuis deux siècles, avec notamment l’avènement de

7 48
SQLI
DIGITAL PERFORMANCE

l’astronomie moderne, les succès incontestables et parfois spectaculaires du déterminisme ont

marqué les esprits. C’est bien la connaissance détaillée des lois de la gravitation et l’application
du déterminisme qui a permis de faire se poser la sonde Curiosity dans un mouchoir de poche
sur Mars le 6 août 2012.
On pourrait citer encore, quoique à degré moindre, le rôle de notre éducation en mathématiques
élémentaires qui, pour d’évidentes raisons pédagogiques, privilégie l’étude des problèmes
linéaires pour lesquels les effets sont proportionnels aux causes et forge ainsi son lot de
fausses intuitions.

Cette quête, souvent inconsciente, d’un déterminisme inexistant dans les projets informatiques
constitue, pensons-nous, l’un des obstacles principaux à surmonter afin d’instaurer une culture
de l’agilité. Elle est en effet à l’origine de résistances comme :

• la difficulté à renoncer à la fausse croyance que l’on peut spécifier intégralement un logiciel
par avance,
• la réticence pour un manager à renoncer au mode de management classique de type
« commande et contrôle » (cf. point 5 ci-dessus).
Ce dernier point fait la transition avec le second facteur de résistance que nous souhaitons
aborder.

8 48
SQLI
DIGITAL PERFORMANCE

LA PEUR DE PERDRE
SES RESPONSABILITÉS
LA PERTE DE CONTRÔLE PAR LES MANAGERS
VIS-À-VIS D’ÉQUIPES TECHNIQUES AUTO-ORGANISÉES,
MENTIONNÉE AU POINT 5, EST RAREMENT ÉVOQUÉE
EXPLICITEMENT EN CES TERMES.
Elle fait plutôt écho à une anxiété sourde et inavouée, particulièrement lancinante en période de
Favoriser l’agilité et la vaches maigres, propice aux questionnements existentiels du genre « à quoi je sers dans cette
créativité exige en réalité de entreprise ? ».
redéfinir la nature même du Ou, plus prosaïquement, « comment puis-je justifier mon salaire auprès de ma direction ? ».
pouvoir des managers et de Les palliatifs usuels, comme se dire systématiquement « over-booké », courir dans les couloirs
transformer son exercice, en arborant des airs importants et enchaîner les réunions, fonctionnent un temps mais ont
d’où précisément le caractère du mal à dissiper l’angoisse sur la durée. L’antidote consiste donc à redéfinir les rôles
anxiogène de l’opération qu’il du management.
s’agit de surmonter.
Dans un monde où les technologies de l’information favorisent l’émergence d’un mode de
production qu’on pourrait qualifier de « sur-mesure de masse », les organisations hiérarchiques
classiques basées sur le mode « commande et contrôle», avec leurs traditionnels jeux de
pouvoir (un terme sur lequel il faudra revenir) s’avèrent non seulement caduques, mais
surtout contre-productives. Il va sans dire qu’on ne crée pas de la valeur dans une industrie en
perpétuelle mutation dont le nerf de la guerre est l’innovation, la créativité et la connaissance
par les mêmes moyens que ceux qui permettent de vendre en masse des produits standardisés3
(Barrand, 2007). En effet, les ressorts psychologiques qui favorisent l’émergence de la créativité
et de l’agilité au sein d’une organisation sont très différents de ceux nécessaires pour faire des
économies d’échelle ou mener des efforts d’automatisation (Taylorisme). Favoriser l’agilité
et la créativité exige en réalité de redéfinir la nature même du pouvoir des managers et de
transformer son exercice, d’où précisément le caractère anxiogène de l’opération qu’il s’agit de
surmonter.

Mentionnons enfin que l’autre extrémité du spectre, celui de l’anarchie organisationnelle, n’est
guère plus propice à la création de valeur, car justement elle inhibe tout processus
d’auto-organisation.
3
Les effets pervers sur l’innovation des excès de rationalisation et d’automatisation, tels qu’on les rencontre parfois dans l’IT, on parle
alors de prolétarisation, ont été analysés par différents auteurs (Stiegler) (P.Lemberger, 2011).

9 48
SQLI
DIGITAL PERFORMANCE

REDÉFINIR LES RÔLES DU MANAGEMENT

Quête d’un déterminisme inexistant et appréhension de perdre ses responsabilités ou son statut,
voilà selon nous les deux principaux obstacles à surmonter pour instaurer une authentique
culture de l’agilité dans le management. La démarche à suivre s’impose donc d’elle-même, elle
procède en deux temps.

Il nous faut d’abord comprendre comment fonctionne une équipe agile que nous assimilerons à
un système dynamique auto-organisé. C’est le sujet qui sera abordé au chapitre suivant. Notre
analyse s’inspire de celle présentée dans (Appelo, 2010)4 et s’appuie sur les sciences de la
complexité5 (Mitchell, 2009), en particulier sur diverses métaphores biologiques. A la lumière
de cette compréhension, nous définirons ensuite les rôles nouveaux qu’il nous semble pertinent
d’attribuer aux managers. Ils tiendront compte de ce qui fait la spécificité de la complexité
sociale de projets informatiques menés sur un mode agile.

Nous en retenons quatre, logiquement imbriqués :

1. Favoriser la compétence et l’autonomie des individus. C’est là un préalable à défaut duquel
l’agilité n’est même pas envisageable,
2. Favoriser l’auto-organisation des équipes. On se focalise dans ce rôle sur les liens entre
individus plutôt que sur les individus eux-mêmes,
3. Définir les bonnes contraintes pour créer de la valeur. L’auto-organisation n’étant pas un
objectif en soi, il s’agit d’en extraire de la valeur en fixant les bonnes conditions,
4. Enfin, le seul moyen de rester dans la course est de créer les conditions d’une amélioration
continue, qui est le dernier rôle.

Il va sans dire que ces quatre rôles sont en réalité partiellement interdépendants et que la
répartition que nous proposons possède, inévitablement, une part d’arbitraire. Cependant, nous
espérons qu’elle aura au moins quelques vertues mnémotechniques.
Le chapitre suivant s’attache à montrer comment différentes disciplines des sciences de la
complexité peuvent jeter une lumière à la fois originale et utile sur la dynamique d’une équipe
agile. Les chapitres 3 à 6 décriront ensuite les quatre rôles qui incombent à un manager agile.
4
Jurgen Appelo, dont le sens du marketing n’est plus à démontrer, est l’auteur de l’expression « Management 3.0 » qui désigne cette
nouvelle conception d’un management basé sur les sciences de la compléxité.

5
Pour une introduction approfondie au sujet nous recommandons l’ouvrage M. Griffith (Mitchell, 2009), lauréat du prix Phi Beta Kappa
2010 qui récompense les ouvrages exceptionnels par leur qualité pédagogique.

10 48
SQLI
DIGITAL PERFORMANCE

AGILITÉ ET
COMPLEXITÉ
ON PRÉSENTE D’ORDINAIRE LES DÉMARCHES AGILES
COMME DES SUBSTITUTS PRAGMATIQUES AUX
MÉTHODES DE CONCEPTION CLASSIQUES, JUGÉES TROP
BUREAUCRATIQUES OU INUTILEMENT FORMELLES.
En outre, lorsque l’on songe au taux d’échec des projets informatiques menés selon ces
Les démarches agiles méthodes classiques, 68% selon certaines sources (Ellis, 2008), (Krigsman, 2008), on se dit
considèrent que le seul objectif qu’un qualificatif probablement plus adéquat serait « irréalistes » voir même
« irrationnelles », tant le déni de réalité est patent. De toute évidence, un ou plusieurs
réaliste est l’optimisation éléments fondamentaux, dans la nature même de ce qu’est un projet informatique, n’ont pas
de l’effort pour produire un été pris en compte.
logiciel qui réponde
aux besoins des utilisateurs.
Voilà qui nous ramène au besoin de causalité. Notre besoin inné de prédictibilité est si puissant
qu’il entretient l’illusion coriace que le temps et la charge pour la réalisation d’un système
informatique sont prédictibles à condition que l’effort de planification ait été suffisant.
Prenant acte de ces observations négatives, les démarches agiles considèrent que le seul
objectif réaliste est l’optimisation de l’effort pour produire un logiciel qui réponde aux besoins
des utilisateurs. Ni l’architecture logicielle détaillée, découverte en cours de route, ni le planning
détaillé ne sont à fournir en début de projet. Toutefois, à l’inverse des méthodes traditionnelles,
dont la prédictibilité est le plus souvent prise en défaut au fur et à mesure de l’avancement du
projet, celle des démarches agiles s’accroît à chaque itération.

Rappelons-en ici quelques principes fondamentaux :

• une équipe agile est auto-organisée et l’essentiel de sa valeur réside dans les interactions
entre individus plutôt que dans la quantité de savoir emmagasinée dans tel ou tel cerveau. Les
individus sont présumés compétents, autonomes et responsables. L’accent sur la qualité est
essentiel,
• toutes les tâches fastidieuses et répétitives (comme les tests unitaires ou l’intégration)
doivent être automatisées pour éviter que s’installe un ennui préjudiciable à la motivation,
• les utilisateurs du logiciel sont activement impliqués dans sa conception et leur représentant
peut à tout moment redéfinir les priorités des différentes fonctionnalités à implémenter,
• le mode de développement est itératif. Chaque livraison apporte son lot de nouvelles
fonctionnalités testables, permettant d’évaluer objectivement l’avancement du projet et
d’obtenir un feedback précoce. Le rythme de travail de l’équipe doit être soutenable.

11 48
SQLI
DIGITAL PERFORMANCE

Les démarches agiles visent donc la flexibilité plutôt que la prédictibilité puisque celle-ci, il faut
bien s’y faire, n’est qu’une illusion.
Pour guider, améliorer et Bien que cela ne soit pas directement lié au sujet du management agile, il est à noter que le
faire croître de telles équipes, constat d’imprédictibilité et l’implication active des utilisateurs que présupposent les démarches
la première responsabilité agiles viennent tous deux remettre en question des traditions bien établies. D’un point de vue
du management sera donc logique, l’imprédictibilité au sens large n’est guère compatible en effet avec la réalisation de
de chercher à comprendre projets au forfait dans laquelle le prestataire est seul à porter le fardeau de l’incertitude. Pour
comment elles fonctionnent ce qui est de l’implication active des utilisateurs, la dichotomie traditionnelle entre MOA et
et quels en sont les principaux MOE chère à nos entreprises françaises n’y est guère favorable. Ces sujets mériteraient à eux
catalyseurs ou inhibiteurs. seuls une étude séparée mais il y a fort à parier que l’agilité prise au sérieux va de pair avec
l’instauration de nouvelles formes de partenariats et d’organisations (intra et inter entreprises).
Bien qu’importants, nous considérons ces problèmes comme des épiphénomènes à mettre sur le
compte d’une vision trop étroitement cartésienne des projets informatiques et des organisations,
qui reste le problème fondamental.

L’origine profonde de cette imprédictibilité, on s’en doute, est la dynamique hautement

non-linéaire d’une équipe de développement. Nous l’envisageons comme un système social
complexe et adaptatif, chargé de convertir en logiciel un besoin utilisateur découvert au fil de
l’eau. Insistons sur le fait que la complexité dont il est question ici n’est en rien liée à la taille de
l’équipe, qui peut être modeste, mais au caractère non déterministe de son fonctionnement.

Pour guider, améliorer et faire croître de telles équipes, la première responsabilité du

management sera donc de chercher à comprendre comment elles fonctionnent et quels en
sont les principaux catalyseurs ou inhibiteurs. La non-linéarité et le caractère auto-organisé
exigent en effet un mode de gouvernance différent du mode hiérarchique usuel que l’on pourrait
qualifier, pour aller vite, de « commande et contrôle » ou de « top down » si l’on préfère.
L’ancien paradigme où l’on assimile implicitement une équipe projet à une sorte de machine
qu’il s’agirait de construire sera remisé au profit d’analogies tirées pour beaucoup du monde
vivant. Il s’agit en effet de faire croître plutôt que de construire.

C’est là que les sciences de la complexité viennent à la rescousse. Le pluriel est ici de mise
car, pour l’heure, il n’existe aucune science unifiée de la complexité mais plutôt un éventail
de disciplines qui impliquent aussi bien les sciences dures que les sciences sociales. D’une
certaine manière, on peut considérer que ces disciplines, par les ponts qu’elles permettent
d’établir6, constituent un antidote rationnel au cloisonnement des connaissances techniques,
scientifiques et sociales. Citons à titre d’exemple certains phénomènes de stabilité dans
l’atmosphère découverts initialement par les météorologues qui ont, par la suite, fait l’objet
d’une étude abstraite par les mathématiciens qui les ont nommés « attracteurs étranges »,
un concept qui s’est finalement avéré utile pour comprendre la récurrence de certains
comportement sociaux, nous y reviendrons.

Voici quelques-unes des disciplines dont nous nous inspirerons pour comprendre le
fonctionnement d’une équipe agile. Les concepts et les métaphores présentés alimenteront
la description des quatre rôles qu’un manager agile devra assumer. Le lecteur pressé pourra
cependant passer directement au chapitre 3 et revenir à cette section en cas de besoin.

12 48
SQLI
DIGITAL PERFORMANCE

LA SYSTÉMIQUE
LA SYSTÉMIQUE SE SITUE AU NIVEAU LE PLUS GÉNÉRAL
DE L’ÉTUDE DES SYSTÈMES, QU’ILS SOIENT COMPLEXES
OU NON.
Plutôt qu’une science constituée, on devrait parler à son sujet d’une approche globale
L’idée d’émergence, qui vise à surmonter les limites inhérentes à toute démarche cartésienne qui procède
à savoir que certains par décomposition d’un système complexe en sous-systèmes intelligibles plus simples.
L’objectif initial de la systémique au début du 20ème siècle était de fournir un vocabulaire
comportements d’un système, ainsi qu’un jeu complet de concepts qui permettraient d’étudier n’importe quel système quel
ne se laissent pas réduire que soit le domaine. Même si cette ambition initiale s’est avérée irréaliste car trop générale,
au comportement de ses les concepts forgés à cette occasion restent d’une grande utilité, notamment pour
composantes est centrale. notre sujet.

La systémique considère qu’un système est complexe lorsque son fonctionnement ne se laisse
pas appréhender par l’analyse des sous-systèmes qui le composent et que son comportement
est à la fois non-linéaire et imprévisible. L’idée d’émergence, à savoir que certains
comportements d’un système, ne se laissent pas réduire au comportement de ses composantes
est centrale.

Dans le cadre d’une équipe agile par exemple, la vision globale d’un système informatique sera
conçue dans cet esprit comme une propriété émergente à l’équipe. Aucun membre ne la détient
à lui seul. Elle résulte de visions individuelles, parfois conflictuelles, qui se confrontent. Cette
idée d’une vision globale conçue comme une entité émergeante est fondamentale. C’est elle qui
légitime la pratique des décisions collégiales dans une équipe agile. La systémique nous enjoint
donc à concentrer notre attention sur les relations entre individus plus que sur les individus
eux-mêmes.

Parmi les autres concepts utiles à notre contexte forgés par la systémique, citons les boucles
de rétroaction. Lorsque la réponse d’un système à une sollicitation externe tend à renforcer
cette cause, on parle de boucle positive, étant bien entendu qu’il ne s’agit pas ici d’un jugement
de valeur. Ce sont tous les effets de type boule de neige, qu’ils soient souhaitables (une équipe
qui a du succès attire de nouveaux talents, ce qui renforce ses chances de succès) ou non
(une mauvaise qualité de code génère du stress qui diminue encore la qualité). Ce type de
boucles amplifie donc les effets de manière non-linéaire et contribue à éloigner un système de
l’équilibre et à le rendre instable. A l’inverse, on parle de boucles négatives lorsque la réponse
d’un système à une sollicitation externe tend à atténuer cette cause. Elles sont facteurs de
stabilité ou d’inertie et l’on conçoit aisément tout l’intérêt de les identifier pour rendre une
organisation efficace et pérenne. Que de petits effets sur un système complexe puissent avoir
de grandes conséquences n’est qu’une conséquence de l’imbrication de ces boucles
de rétroaction multiples.

13 48
SQLI
DIGITAL PERFORMANCE

Le concept d’itération,
proche de l’acception du terme
dans les démarches agiles,
y est introduit.

LA CYBERNÉTIQUE
Etroitement liée à la systémique, la cybernétique étudie plus spécifiquement les systèmes
complexes soumis à des buts et régulés par des boucles de rétroaction négatives. Elle étudie
donc les mécanismes de causalité circulaires et les flux d’informations qui circulent entre un
système et son environnement7. Le concept d’itération, proche de l’acception du terme dans
les démarches agiles, y est introduit. Après qu’un système a agi sur son environnement, on
étudie l’impact de cette action et enfin l’on compare cet impact à ce qui était prescrit dans les
buts assignés. Enfin, la cybernétique étudie aussi comment de nouveaux équilibres peuvent
s’instaurer dans un système complexe à partir de situations de déséquilibre, un constat
particulièrement utile dans le management d’équipes agiles comme on le verra au chapitre 6.

Plus récemment, la cybernétique a également introduit l’idée que l’observateur d’un système
doit s’inclure lui-même lorsqu’il analyse un système dont il affecte le comportement par
sa présence. Ce point de vue marque une rupture épistémologique aussi considérable que
l’abandon de la démarche analytique déjà évoquée. Un manager par exemple devra se connaître
lui-même pour bien manager. En ce sens, on le voit, les conclusions de la cybernétique
rejoignent à la fois l’antique sagesse du précepte « Connais-toi toi-même ! » et l’idée que le seul
pouvoir véritablement utile est celui qu’on exerce sur soi-même.

L’idée de rétroaction est bien sûr fondamentale dans les projets informatiques puisqu’une
grande part de l’imprédictibilité qui les affecte tient à l’impact, à priori inconnu, qu’un logiciel
aura dans le contexte social dans lequel il est introduit. A ce titre, assimiler un système
d’information à une sorte de machine compliquée qui aurait une existence et des qualités
propres, indépendantes des utilisateurs, n’est qu’un leurre.
7
La cybernétique, contrairement à la systémique, a par ailleurs fait l’objet d’un travail de modélisation mathématique avancé, notam-
ment dans les mains de Norbert Wiener qui en a énoncé les concepts, dont la célèbre boîte noire.

14 48
SQLI
DIGITAL PERFORMANCE

LA THÉORIE DES SYSTÈMES

DYNAMIQUES ET LE CHAOS
LA THÉORIE DES SYSTÈMES DYNAMIQUES FAIT PARTIE
DE LA PHYSIQUE THÉORIQUE ET ÉTUDIE L’ÉVOLUTION DE
SYSTÈMES SOUMIS À DES LOIS DÉTERMINISTES.
L’un des principaux intérêts de cette théorie est qu’elle permet de comprendre les
L’expérience montre que mécanismes de transition entre des situations où la dynamique d’un système est régulière
des comportements complexes et celles où son comportement devient chaotique. Elle permet en particulier de réconcilier
résultent le plus souvent le déterminisme avec les idées d’imprédictibilité et de chaos, c’est le phénomène bien connu
de sensitivité aux conditions initiales, appelé aussi l’effet papillon. Par ailleurs, pour nombre
de l’influence conjointe de concepts déjà évoqués comme le chaos, la stabilité, l’imprédictibilité ou le déterminisme,
d’une force de freinage interne cette théorie fournit des concepts mathématiques dépourvus de toute subjectivité.
et d’une force externe qui, elle,
tend à créer le mouvement.
Beaucoup de systèmes complexes réels sont dits dissipatifs, c’est-à-dire qu’ils sont soumis
à une force de freinage qui tend à les ramener vers une situation d’équilibre. L’expérience
montre que des comportements complexes résultent le plus souvent de l’influence conjointe
d’une force de freinage interne et d’une force externe qui, elle, tend à créer le mouvement. Le
système résout alors ce conflit en adoptant sur le long terme un certain comportement limite.
Selon les cas, ce comportement limite pourra être statique, cyclique ou complexe. On parle
d’attracteur lorsque le système s’en approche à long terme, indépendamment des conditions
initiales précises. Enfin, celui-ci est dit étrange, lorsqu’il correspond à un comportement limite
complexe : un attracteur étrange est donc une structure émergente qui apparaît à la frontière
entre l’ordre (incarné par la structure de l’attracteur) et le chaos (qui empêche toute prévision
précise quant à la localisation du système sur cet attracteur). Mentionnons enfin que l’ensemble
des conditions initiales qui amènent le système à converger vers un attracteur est appelé son
bassin d’attraction.

Figure 1 :
Figure 1 : Deux attracteurs A1, A2 et leur bassin
d'attraction B1, B2. Le lien S représente un saut
de grande ampleur qui permet de passer d’un
bassin à un autre.

En bref, la théorie des systèmes dynamiques explique pourquoi, dans certaines circonstances,
le comportement à long terme d’un système échappe à toute velléité de le contrôler au moyen
d’un ajustement des conditions initiales.
La relation avec notre sujet est alors immédiate : combien de fois, dans nos projets
informatiques, n’avons-nous pas observé des situations qui se répètent, le plus souvent contre
notre gré, alors même que nous pensions avoir fait le nécessaire pour nous en prémunir ?
Combien de DSI finissent par consacrer l’essentiel de leur budget informatique à la maintenance
de systèmes anciens alors que leur ambition initiale était de diminuer les coûts à grand renfort
de technologies flexibles et d’architecture SOA (David Shpilberg, 2007) ?
Le message de la théorie des systèmes dynamiques est que dans de telles situations il
peut s’avérer judicieux de changer de bassin d’attraction ou, plus radicalement, de déplacer
l’attracteur, un sujet qui sera abordé au chapitre 6.

15 48
SQLI
DIGITAL PERFORMANCE

LES AUTOMATES CELLULAIRES

ET LES SYSTÈMES ADAPTATIFS
Une classe de systèmes dynamiques particulièrement intéressantes à considérer, par
la richesse des analogies qu’elle suggère, est celle des automates cellulaires. Plutôt que d’en
donner une définition abstraite, illustrons le concept par un exemple, celui du célèbre « Jeu de
la Vie » (Gardner, 1970) inventé par John Conway. L’univers de ce système est constitué par un
quadrillage à deux dimensions dans lequel chaque cellule peut-être soit vivante, soit morte.
A partir d’une configuration initiale l’évolution du système est régie par trois règles spécifiques
qui définissent les états successifs de chaque cellule en fonction de l’état des cellules
adjacentes8. L’un des intérêts du « Jeu de la Vie » (qui en réalité n’est pas un jeu !) c’est
la richesse prodigieuse de comportements qui émergent de ces trois règles9.

Figure 2 :

Figure 2 : Une configuration de l’automate

cellulaire du « Jeu de la Vie ».

Ce qui en fait une source d’inspiration dans le cadre du management agile, c’est la question
cruciale du choix des règles communes aux équipes agiles et aux automates cellulaires.
Choisies au hasard, l’immense majorité des règles conduit à des automates dont le
comportement, parfaitement ennuyeux, est assimilable aux attracteurs stables ou périodiques
évoqués plus haut. De fait, il a fallu tout le génie et la persévérance d’un J. Conway pour
parvenir à débusquer le jeu des trois règles spécifiques au « Jeu de la Vie » qui, à la frontière
de l’ordre et du chaos, engendre un comportement complexe et créatif. Dès lors, la question qui
tombe sous le sens est la suivante : un manager est-il à une équipe agile ce que J. Conway a été
au « Jeu de la Vie » ? En d’autres termes, le rôle d’un manager est-il de définir les bonnes règles
pour faire en sorte que son équipe soit créative et productive ? D’emblée, vendons la mèche, la
8
Explicitement : une cellule morte devient vivante lorsque 3 cellules adjacentes sont vivantes, une cellule vivante le reste si 2 ou 3
cellules adjacentes sont vivantes, une cellule meurt ou reste morte dans tous les autres cas.

9
Il a prouvé par exemple, qu’au moyen de configurations initiales judicieuses et extrêmement complexes, le Jeu de la Vie était capable
d’effectuer n’importe quel calcul.

16 48
SQLI
DIGITAL PERFORMANCE

Les systèmes complexes

performants dans la nature
n’ont pas de commandement
central. Le rôle du manager
n’est pas de commander à
des individus mais plutôt de
manager des équipes pour
qu’elles prospèrent comme des
êtres vivants sains.

réponse est non, mais la justification détaillée interviendra au chapitre 5.

Pour l’instant, remarquons qu’à la différence des automates cellulaires, une microsociété
telle qu’une équipe agile est capable de se doter de ses propres règles. Elle est susceptible
d’auto-organisation en ce sens qu’elle est capable de se maintenir, par elle-même, dans cette
zone fragile de créativité, à la lisière du chaos. Elle fonctionne en réalité comme un système
complexe adaptatif c’est-à-dire comme un système de règles en perpétuelle réévaluation.
L’évaluation des règles procède par comparaison entre l’état actuel du système et l’état
correspondant au but assigné au système. En l’occurrence : réaliser un logiciel qui satisfasse les
utilisateurs. Dans cette vision, l’une des responsabilités du manager sera de faire en sorte que
l’équipe agile puisse élaborer ses propres règles. Ce sujet sera abordé aux chapitres 3, 4 et 5.

L’un des principaux messages au management de la part des sciences de la complexité et en

particulier de la biologie est le suivant : les systèmes complexes performants dans la nature
n’ont pas de commandement central. Le rôle du manager n’est pas de commander à des
individus mais plutôt de manager des équipes pour qu’elles prospèrent comme des êtres vivants
sains.

Une dernière remarque de prudence : il ne saurait être question pour un sujet aux contours aussi
flous que le management agile, de découvrir de prétendues lois universelles, encore moins de
prouver des théorèmes que l’on pourrait asséner comme des vérités absolues à un interlocuteur
dubitatif. Les contreparties à l’utilisation de métaphores issues d’un large éventail de disciplines
scientifiques comme nous le faisons sur les traces de Jurgen Appelo, sont la prudence et l’esprit
critique. Appliquer les concepts et les idées des sciences de la complexité au management
d’équipes agiles, remplacer les antiques intuitions cartésiennes par de nouvelles, plus
rationnelles et mieux adaptées à la complexité technique et sociale des projets informatiques,
tels sont les objectifs du management agile.

17 48
SQLI
DIGITAL PERFORMANCE

FAVORISER
LA COMPÉTENCE
ET L’AUTONOMIE
LES DANGERS CACHÉS
DES « BONNES PRATIQUES »
L’UN DES PRINCIPES RÉCURRENTS DANS LES MÉTIERS
DE L’INFORMATIQUE EST CELUI DE LA CAPITALISATION.
Eviter de réinventer la roue, ne pas refaire ce qui a été fait à maintes reprises ailleurs par
d’autres, surtout leurs erreurs, voilà qui ne semble guère devoir être remis en question.
Puisqu’il est question ici d’agilité, considérons à titre d’exemple le génie logiciel. Sont apparus
successivement dans cette discipline des principes de conception réutilisables, communément
appelé « design patterns » (Erich Gamma, 1994), des API10 qui formalisent ces principes dans
des langages de programmation spécifiques et, enfin, des implémentations de ces API sous
forme de framework réutilisables. La réutilisation dans le génie logiciel concerne donc aussi
bien les concepts que leur mise en œuvre effective sous forme de code. D’autres référentiels
offrent des listes de bonnes pratiques, plus ou moins effrayantes (ou soporifiques) par leur
ampleur, pour des sujets aussi variés que l’architecture des systèmes d’information (TOGAF)
le management de système d’information (ITIL, CoBiT) ou encore pour l’amélioration de la
qualité des développements (CMMI). Les démarches agiles ont à leur tour été formalisées sous
forme de manifestes ou de crédos plus ou moins flamboyants (Scrum, RUP, Lean Software
Development, la méthode Kanban).
Si elle est légitime et souvent même indispensable, la démarche de capitalisation, poussée
à l’extrême, peut aussi engendrer des effets pernicieux dont il faut être conscient. L’excès de
confiance dont font l’objet certains référentiels de bonnes pratiques peut susciter un dangereux
sentiment de fausse sécurité. Des processus peaufinés pendant des lustres, avec leur
batteries d’indicateurs, de rituels et des compte-rendus utilisant le bon modèle de document
deviennent alors que des paravents qui retardent la solution des vrais problèmes et mènent à
la catastrophe. Les processus constituent un cadre de travail mais ils ne produisent pas d’idées.
10
API = Application Programming Interfaces

18 48
SQLI
DIGITAL PERFORMANCE

L’exigence de compétence
et d’autonomie doit primer
sur le souci d’amélioration
des procédures. L’application
scrupuleuse d’un référentiel
de bonnes pratiques, quel
qu’il soit, ne pourra jamais se
substituer à la compétence et
au sens des responsabilités
des individus.

La méconnaissance de la complexité des projets informatiques de la part de responsables

n’ayant jamais mis les mains dans le cambouis ne fait qu’alimenter cet excès de confiance.
Ne négligeons pas non plus le rôle néfaste de la mauvaise foi, cette forme de couardise qui
fait préférer l’abri confortable des procédures aux risques inhérents à toute formulation d’un
jugement personnel et à toute prise de responsabilité.
L’une des caractéristiques des projets informatiques sur lesquelles on n’insiste pas assez,
c’est que leur complexité ne se laisse pas maîtriser par des procédures, des « templates » ou
des algorithmes uniquement. Voilà qui nous amène finalement au sujet de ce chapitre : pour
faire face à ce caractère irréductible d’une situation complexe particulière, la compétence et
l’autonomie sont indispensables. Elles sont en réalité des préalables pour gérer la complexité
sur un mode agile. La remarque peut paraître banale, mais trop d’exemples nous viennent à
l’esprit pour que nous omettions de rappeler ici ce fait fondamental. L’exigence de compétence
et d’autonomie doit primer sur le souci d’amélioration des procédures. L’application scrupuleuse
d’un référentiel de bonnes pratiques, quel qu’il soit, ne pourra jamais se substituer à la
compétence et au sens des responsabilités des individus.
Cette remarque prend toute sa signification dans un contexte où l’innovation et la créativité
jouent un rôle prépondérant. On ne peut en effet ni décider, ni planifier l’innovation, on peut
tout au plus la cultiver dans un environnement social où sont promues des valeurs comme
l’excellence technique, la curiosité, l’originalité, le sens de l’initiative, fût-ce au coût d’un zeste
de désobéissance et d’irrévérence.

19 48
SQLI
DIGITAL PERFORMANCE

UNE DÉFINITION DE LA COMPÉTENCE

Mais qu’est-ce que la compétence au juste ? Dans un premier temps on pense évidemment au
Les profils de spécialistes savoir-faire professionnel et aux connaissances académiques. Un développeur par exemple doit
qui se généralisent maîtriser un certain nombre de langages de programmation, quelques principes de conception
progressivement sont souvent ainsi qu’un environnement de développement. Pourtant, le savoir-faire à lui seul ne suffit pas.
les plus utiles dans les projets Que dire en effet d’un développeur féru de toutes les API Java/JEE mais incapable de tenir le
car leur culture générale IT se moindre engagement de délai ou de qualité ? A l’évidence il ne pourra être qualifié de compétent
conjugue avec l’expérience de car il lui manque une qualité tout aussi essentielle que le savoir-faire : la discipline. Nous
ce que coûte le développement parvenons ainsi à l’équation (Appelo, 2010) :
d’une réelle expertise. Compétence = (Savoir-faire) * (Discipline)
Savoir-faire et discipline sont deux qualités indépendantes, l’une pouvant être présente chez un
individu sans que l’autre ne le soit. Elles devront pour cette raison être développées séparément
par les managers.
Assurer un haut niveau de savoir-faire suppose naturellement de recruter des profils
initialement bien formés mais aussi de leur garantir par la suite la possibilité de se former en
continu. Les profils de spécialistes qui se généralisent progressivement sont souvent les plus
utiles dans les projets car leur culture générale IT se conjugue avec l’expérience de ce que coûte
le développement d’une réelle expertise.
Paradoxalement, la perte de savoir-faire peut aussi résulter de certains progrès technologiques
lorsque ceux-ci permettent l’automatisation de tâches au préalable manuelles. On peut
anticiper par exemple que la généralisation des applications en mode PaaS11 conduira à la perte
progressive de savoir-faire liés au déploiement d’applications sur des machines locales et à la
maintenance d’une infrastructure matérielle.
11
PaaS = Platform as a Service

20 48
SQLI
DIGITAL PERFORMANCE

Le stimulus externe peut même

avoir un effet opposé à celui
qui était à l’origine
de l’incitation.

LES DIFFÉRENTS TYPES

DE MOTIVATION
Après le savoir-faire, passons au deuxième facteur de la compétence : la discipline. Largement
tributaire de la motivation des individus, un manager devra s’attacher à la maintenir à un niveau
raisonnable dans ses équipes et donc à en comprendre les diverses facettes.
Lorsqu’une source de motivation est externe à un individu, on parle généralement de motivation
extrinsèque. Entrent dans cette catégorie les formes classiques d’incitations et de récompenses
comme les bonus financiers, les promotions ou même les compliments adressés pour
l’accomplissement d’un bon travail.
Remarquons que ce types de mécanismes d’incitation, ou à l’inverse de sanction, reposent,
là encore, sur un postulat déterministe s’agissant du comportement des individus. On
présuppose qu’il est possible de trouver des causes adéquates pour susciter un certain type de
comportement chez certains individus, qu’il s’agisse d’un surcroît de discipline, de qualité du
travail ou d’investissement personnel. Bien que ce mode de fonctionnement soit effectivement
présent à des degrés divers chez tous les humains, de nombreuses études en sciences sociales
ont montré de manière particulièrement probante (Pink, 2011) que ce type de mécanisme était
non seulement inefficace dans beaucoup de cas, mais était même contre-productif. Et ceci
d’autant plus que les tâches à réaliser exigeaient un niveau élevé de créativité. Parmi les effets
secondaires néfastes engendrés par de telles incitations on peut citer, pêle-mêle, l’addiction aux
incitations, la destruction de la loyauté, de la créativité et de la solidarité, la perte de sens du
travail, la création de compétitions inutiles entre collaborateurs et la diminution de l’aptitude à
résoudre des problèmes complexes.
Dans des cas extrêmes, le stimulus externe peut même avoir un effet opposé à celui qui
était à l’origine de l’incitation. On a donc là un comportement manifestement non-linéaire et
imprévisible. Mentionnons à titre d’exemples, presque comiques, ces développeurs rémunérés
aux nombres de bugs corrigés par jour qui en inventaient de nouveaux pour arrondir leurs
fins de mois ou ces employés d’un centre d’appels rémunérées au nombre d’appels pris qui
raccrochaient régulièrement au nez des clients, histoire de faire grimper leur compteur.
En conclusion, on voit que l’inconvénient principal des motivations extrinsèques est leur

21 48
SQLI
DIGITAL PERFORMANCE

Une phrase clé, pour un

manager pourrait-être
celle-ci: « Que puis-je faire
pour que vous donniez le
meilleur de vous-même ? ».

tendance à engendrer des comportements qui n’ont de la vertu que l’apparence. On se contente
de faire semblant. Un comportement authentiquement vertueux qui s’attache à produire un
travail de qualité est quant à lui la conséquence d’une motivation intrinsèque. L’essence de la
motivation intrinsèque est une activité qui est sa propre récompense, car porteuse de sens pour
celui qui l’exerce.

Ce type de motivation est beaucoup plus stable que le précédent et ne souffre pas d’effets non
linéaires indésirables puisque la cause et les effets de la satisfaction, l’activité elle-même,
sont confondus. Les origines psychologiques de la motivation intrinsèque sont multiples et
s’enracinent profondément dans la quête de sens que chacun cherche à donner à ses activités
: désir de se sentir compétent, d’être maître de son destin, de nouer des relations avec des
individus pour qui on a de l’estime, d’être partie prenante d’un projet auquel on adhère et qui
nous dépasse.
Bien entendu, il est difficile voire impossible pour un manager, sauf à être un authentique
sage, de créer de la motivation intrinsèque chez des collaborateurs qui en sont dépourvus. Ce
à quoi ils peuvent contribuer en revanche, c’est de garantir des conditions d’hygiène de travail
qui, lorsqu’elles sont absentes, la détruisent : la sécurité du travail, des conditions de travail
décentes, et bien sûr un salaire en relation avec les compétences exercées. Une phrase clé,
pour un manager pourrait-être celle-ci: « Que puis-je faire pour que vous donniez le meilleur de
vous-même ? ».

22 48
SQLI
DIGITAL PERFORMANCE

POURQUOI L’AUTONOMIE ?
L’AUTONOMIE EST UN SUJET PLUS SUBTIL QUE CELUI
DE LA COMPÉTENCE.
On conçoit bien tout d’abord qu’un degré d’autonomie minimal soit nécessaire pour
qu’émerge l’auto-organisation dans un contexte agile où les décisions sont collégiales.
Pourtant, l‘autonomie n’est pas seulement une exigence, elle est aussi un moyen de
valoriser les individus, les collaborateurs comme les managers. Nul besoin d’être un expert
en psychologie pour concevoir qu’un collaborateur, à qui son manager accorde un niveau
d’autonomie adapté à son expérience, se sentira valorisé et reconnu dans ses compétences.
On distingue trois niveaux d’autonomisation pour les collaborateurs (Appelo, 2010) :

Autonomie faible
Elle consiste à déléguer des tâches qui n’ont pas beaucoup d’impact sur la marche de
l’entreprise. Pour une équipe de développement on peut ranger dans cette catégorie la définition
de conventions de nommage et de codage et l’animation de séminaires internes.

Autonomie modérée
Cette catégorie correspond au niveau d’autonomie souhaitable dans un contexte agile. Elle
comprend des tâches comme la participation au recrutement de nouveaux collaborateurs, la
possibilité de choisir ses heures de travail, le choix des outils de travail ou encore la prise
d’initiative pour développer de nouvelles offres.

Autonomie importante
Enfin dans cette catégorie on trouve les associés. Ceux-ci choisissent eux-mêmes les projets
sur lesquels ils souhaitent travailler et leur lieu de travail. Ils déterminent collégialement leurs
salaires.

L’autonomisation des collaborateurs est un investissement à long terme qui exige de la

patience. Malgré les tentations, un manager doit éviter d’appliquer l’adage « la meilleur solution
pour qu’une tâche soit menée à bien c’est de la réaliser soi-même ». Il devra en revanche
assumer la délégation des tâches qu’il à confiées à ses collaborateurs, la pire erreur étant de
reprendre ce qui a été donné.
L’autonomisation apporte des bénéfices non seulement aux collaborateurs qui en sont gratifiés
mais aussi au manager qui l’accorde. Celui-ci voit son statut et sa crédibilité renforcés car

23 48
SQLI
DIGITAL PERFORMANCE

la confiance qu’il accorde à ses collaborateurs témoigne de l’assurance tranquille de celui qui
sait s’entourer d’individus compétents et par conséquent sait se rendre dispensable. Voilà l’un
des meilleurs antidotes à la peur de perdre ses responsabilités mentionnée dans l’introduction.
Il existe encore une autre motivation pour autonomiser les collaborateurs, directement liée
à l’initiation du processus d’auto-organisation que nous aborderons au chapitre 4. Chaque
manager en a fait l’expérience à ses dépens, certaines informations au sein d’une organisation
ont la fâcheuse tendance à contourner les nœuds de décisions. Souvent par appréhension
des conséquences pour qui se fait le messager de questions délicates. Parfois aussi, par
simple souci d’efficacité car on imagine, à tort ou à raison, que ces nœuds sont déjà saturés
d’informations et de décisions à prendre. Au chapitre 5 nous verrons qu’il existe pour une
organisation agile un principe, le principe de subsidiarité, qui consiste à affecter toute prise
de décision à l’échelon hiérarchique le plus bas possible. Il s’agit en réalité d’un principe
d’efficacité et non d’un souci de démocratie. Beaucoup de problèmes, surtout s’ils sont
d’ordre technique ou s’ils relèvent de l’affectation de tâches quotidiennes sont résolus plus
efficacement lorsque les prises de décisions sont affectées aux individus qui détiennent
l’information la plus détaillée et la plus récente. Or celle-ci est souvent détenue par les
membres de l’équipe agile eux-mêmes. L’autonomisation des individus rend ce principe
applicable et contribue ainsi à distribuer le traitement de l’information dans tout le réseau social
plutôt que dans quelques nœuds. On parle alors de micro-management.
Déléguer des responsabilités à des individus autonomes présuppose naturellement
l’instauration d’un climat de confiance, nous y reviendrons au chapitre suivant.

24 48
SQLI
DIGITAL PERFORMANCE

FAVORISER
L’AUTO-ORGANISATION
DES ÉQUIPES
L’AUTO-ORGANISATION N’EST PAS UNE
« BONNE PRATIQUE » !
Ce qui est artificiel, c’est
SUPPOSONS QU’À LA LUMIÈRE DU CHAPITRE PRÉCÉDENT
d’imaginer que le schéma UN MANAGER N’AIT AFFAIRE QU’À DES INDIVIDUS
classique d’un commandement
émanant d’une autorité
COMPÉTENTS, AUTONOMES ET MOTIVÉS, POUR
centrale, suivi du contrôle CONSTITUER SES ÉQUIPES.
de son exécution, puisse
fonctionner pour élaborer des L’hypothèse peut sembler hardie, mais nous la faisons pour la clarté dans notre argumentation.
systèmes complexes fiables. Reste encore à constituer cette collection d’individualités compétentes en équipes auto-
organisées. Pour que la mayonnaise prenne, encore faut-il que plusieurs conditions soient
réunies. Les individus les plus compétents par exemple n’ont pas nécessairement envie de
travailler ensemble. Il s’agit donc de créer du lien entre les individus car la performance
d’un système social complexe comme une équipe agile tient souvent d’avantage à la qualité
des liens du réseau qu’à l’expertise associée à chacun de ses nœuds. Ceci est d’autant plus
important dans les domaines comme l’IT où une grande part du savoir est de nature implicite et
ne s’acquiert pas par l’étude d’ouvrages mais par assimilation lors de collaborations informelles
au sein d’équipes projets.

Deux conditions sont incontournables pour qu’émerge ce lien : la confiance entre les membres
de l’équipe ainsi qu’un objectif partagé par tous. Ce sont les sujets des deux prochaines sections
ainsi qu’en partie du chapitre 5. Mais, avant cela, revenons un instant sur l’auto-organisation elle
même. On aurait tort de penser qu’il s’agit d’un phénomène exotique ou artificiel.
En réalité l’auto-organisation est le phénomène le plus naturel du monde. Ce n’est pas une
« bonne pratique », c’est plutôt la pratique par défaut d’une majorité de systèmes adaptatifs.
Les systèmes vivants en témoignent de manière particulièrement probante, aucun designer

25 48
SQLI
DIGITAL PERFORMANCE

n’ayant jamais conçu (à notre connaissance) une cellule vivante, une fourmi ou un éléphant. Les
systèmes complexes et stables comme les organismes vivants n’ont pas été conçus par une
autorité centrale mais ont crû pour s’adapter à leur environnement lui-même changeant.
Ce qui est artificiel, voire irrationnel, c’est le fait de prétendre concevoir et planifier par avance
des systèmes complexes en interaction avec un système social, comme s’il s’agissait de
machines. Ce qui est artificiel, c’est d’imaginer que le schéma classique d’un commandement
émanant d’une autorité centrale, suivi du contrôle de son exécution, puisse fonctionner pour
élaborer des systèmes complexes fiables.

Pour qu’émerge le phénomène d’auto-organisation deux conditions doivent être remplies.

D’une part, le système adaptatif doit posséder une frontière bien définie. C’est le cas par
exemple d’une cellule vivante. Il en ira donc de même pour une équipe agile. Pour que s’initie le
processus d’auto-organisation, il faudra que chaque équipe soit identifiée comme telle, et par
conséquent que chacun sache sans ambigüité à laquelle il appartient. D’autre part, il faut qu’un
objectif ait été assigné à cette équipe pour qu’elle crée de la valeur, un sujet qui sera traité en
détail au chapitre 5.

Le reste de ce chapitre est organisé comme suit. Nous examinerons dans un premier temps
comment réaliser les deux conditions indispensables à l’auto-organisation : la création de
liens de confiance et l’assignation d’un objectif à une équipe. Le maintien d’une saine dose de
diversité dans les profils d’une équipe est une mesure d’hygiène importante à plus d’un titre,
ce sera le sujet d’une autre section. Les deux dernières sections enfin seront consacrées à
l’émergence de la créativité et à la construction d’une vision globale d’un système informatique
complexe. La création de valeur est aussi une propriété émergente, c’est même la plus
importante de toute, le chapitre 5 lui sera entièrement consacré.

26 48
SQLI
DIGITAL PERFORMANCE

CRÉER LA CONFIANCE
LA CONFIANCE QUE L’ON ACCORDE À UN
COLLABORATEUR OU UNE ÉQUIPE EST CET ÉTAT D’ESPRIT
QUI PERMET DE TRAVAILLER SANS ARRIÈRE-PENSÉE
Indépendamment même de toute considération éthique, elle est un facteur d’efficacité
opérationnelle. Elle simplifie la vie en minimisant la quantité d’informations à échanger pour
effectuer une certaine tâche de même que le nombre de contrôles à effectuer. Bien souvent elle
pourra se substituer avec profit à l’échafaudage laborieux de contrats qui prétendent anticiper
toutes les figures imaginables de mauvaise foi. Evidemment, la confiance ne se décrète pas.
Elle se gagne, lentement. Elle est accordée à celui ou celle dont les actes coïncident le plus
souvent avec les intentions affichées. Girouettes, manipulateurs et opportunistes sont,
à l’inverse, de véritables trous noirs pour la confiance : ils la détruisent durablement.

Figure 3 :

Figure 3 : Les relations de confiance entre un

manager dans l’ordre où elles devraient être
3
instaurées.

27 48
SQLI
DIGITAL PERFORMANCE

Le premier devoir, particulièrement pour un manager, est d’avoir confiance en soi.

C’est une condition indispensable pour gagner celles des autres, tant il est vrai que la plupart
des humains ont une aptitude remarquable à déceler les signaux de fausseté, mêmes
infinitésimaux. La confiance en soi exige de ne pas se mentir à soi-même et de rester fidèle
à ses convictions, même en présence de pressions politiques ou d’avis divergents. Enfin, et dans
le même ordre d’idées, n’oublions pas que l’un des moyens les plus efficaces, mais aussi
les plus difficiles pour susciter la confiance, est de savoir reconnaître sereinement
ses propres faiblesses.

S’agissant de la confiance qu’un manager décide d’accorder à un collaborateur ou à une

équipe, celle-ci doit être assumée par lui. En clair, si cette confiance était trahie par l’un de ses
collaborateurs, il sera responsable de la confiance qu’il a décidé d’accorder.
La relation entre un manager et son équipe est évidement asymétrique. Pour cette raison c’est
à lui d’initier le cercle vertueux de la confiance en attribuant, sans attendre de retour immédiat,
la sienne à son équipe. Non pas pour se défausser de ses propres responsabilités, mais pour
investir ses collaborateurs d’un surcroît de pouvoir et par conséquent de responsabilités. Une
manière courante hélas de détruire ce type de confiance, parfois par inadvertance, consiste pour
un manager à réaliser lui-même une tâche qu’il avait confiée à un collaborateur ou à prendre
une décision à sa place.

Un manager peut contribuer activement à l’instauration d’un climat de confiance entre membres
d’une équipe en jouant sur le caractère transitif de la relation de confiance. Imaginons que
Pierre et Paul, fassent partie de l’équipe de Jacques et n’aient pas encore établi de lien de
confiance. Celle-ci pourra naître dès lors que Pierre et Paul entretiennent tous deux une relation
de confiance avec Jacques, leur manager, qui jouera alors le rôle de nœud de confiance dans
le réseau. Enfin un manager doit aussi s’assurer que chacun puisse s’exprimer librement ; en
multipliant les occasions de prises de parole informelles par exemple. Il peut aussi aider les
individus à tenir leurs propres engagements ou les inciter à annoncer ouvertement qu’ils ne
parviendront pas à les tenir.

28 48
SQLI
DIGITAL PERFORMANCE

QUELS BUTS POUR QUI ?

NOUS ABORDONS ICI LA SECONDE CONDITION POUR QUE
S’ENCLENCHE L’AUTO-ORGANISATION : L’ASSIGNATION
D’UN BUT À UNE ÉQUIPE.
Par là, nous anticipons en partie le sujet du chapitre 5 consacré à la définition de contraintes
Pour une équipe propres à créer de la valeur. La notion de but ou d’objectif est cependant plus subtile et plus
de développement ce but riche, on le verra, que la simple assignation par une instance externe d’un objectif à une équipe
intrinsèque peut être assimilé agile. Ce sujet est délicat pour deux raisons. D’une part, les sciences dures ont coutume de
à « créer du logiciel » considérer que les questions liées à la finalité ou au sens doivent être maintenues hors du
champ scientifique. Ceci peut donc créer chez certains une inhibition à aborder les questions
touchant au « pourquoi » d’une activité. Nous pensons au contraire, en accord avec les
chercheurs en sciences sociales, que ce sujet est tout à fait sérieux et qu’on ne peut manquer
de l’aborder lorsqu’il s’agit de clarifier le rôle du management. Une seconde source de difficulté
tient au fait que les termes même d’objectif, de but ou de sens, qu’on les applique à une
entreprise, à une équipe ou à un individu, possèdent une sémantique qui prête à confusion.
Notre première tâche sera donc d’y mettre bon ordre.
Nous inspirant de (Geus, 1997) et (Appelo, 2010), nous définirons trois concepts distincts de
buts. Tous s’appliquent à un organisme vivant auquel nous assimilerons par la suite une équipe
agile ou plus généralement une organisation.

Le but intrinsèque
Chaque organisme vivant possède une tendance innée à la survie. C’est cette tendance
naturelle et spontanée que l’on définit comme étant son but intrinsèque. Pour une équipe de
développement ce but intrinsèque peut être assimilé à « créer du logiciel », faute de quoi en
effet elle n’a plus de raison d’être et sera dissoute. Un point important sur lequel il convient
d’insister est que le but intrinsèque d’un système vivant ou d’un système social doit être
compris comme une propriété émergente. C’est une résultante des interactions entre les sous-
systèmes qui le composent. Le but intrinsèque d’un brin d’ADN par exemple est de se répliquer
alors que le but intrinsèque d’un organisme vivant est de survivre. De même, le but d’une équipe
de développement -créer du logiciel - peut lui aussi être très différent des buts autonomes des
membres qui la composent (voir plus loin).

Le but extrinsèque
Cette notion de but extrinsèque n’a de sens que lorsqu’un organisme vivant possède un
propriétaire, un directeur ou un chef. C’est alors le but assigné par son propriétaire à cet
organisme. Le but extrinsèque d’un chien de chasse est de ramener du gibier à son maître.

29 48
SQLI
DIGITAL PERFORMANCE

La définition d’un but

autonome s’inscrit dans
la quête de sens
profondément enracinée
dans tout être humain.

Le but extrinsèque d’une équipe de développement lui est assigné en début de projet par un
manager, par des utilisateurs ou par un Product Owner. C’est l’une des contraintes à imposer
pour que l’auto-organisation crée de la valeur, nous y reprendrons au chapitre 5.

Le but autonome
Cette dernière acception du terme « but » présuppose l’existence d’une conscience, d’une
volonté propre ou, si l’on préfère, d’un libre arbitre pour le système complexe en considération.
Une fourmi ne peut avoir de but autonome car elle n’a pas de libre arbitre. Un être humain ou
un organisme social peuvent en revanche décider de se donner un tel but. Le but autonome de
tel développeur pourra être d’écrire du code élégant, celui de tel autre sera de finir son travail
aussi rapidement que possible pour pouvoir se consacrer à sa famille etc. La définition d’un but
autonome s’inscrit dans la quête de sens profondément enracinée dans tout être humain. Nous
avons besoin de nous percevoir comme partie prenante d’un processus auquel nous pouvons
attribuer un sens. La réalisation d’un but autonome est en réalité le seul vrai moteur, c’est lui qui
rend possible l’émergence d’un but intrinsèque.

Des trois notions de buts que nous venons d’évoquer, seul le but extrinsèque possède un sens
pour un système mécanique ou une machine, pour la bonne et simple raison qu’on peut les
posséder. Le but intrinsèque est une spécificité des êtres vivants. Le but autonome est le propre
d’êtres doués de conscience. Croire qu’on pourrait assimiler ces derniers à des machines est
l’une des erreurs les plus grossières auxquelles peut conduire l’excès de cartésianisme.
A la lumière de ces clarifications sémantiques on comprend mieux le caractère fallacieux
d’affirmations, récurrentes dans certains milieux, du genre : « le but premier d’une entreprise
est d’enrichir les actionnaires ». C’est évidemment une confusion grossière des termes.
L’enrichissement des actionnaires n’est que le but des actionnaires eux-mêmes et non pas
celui des individus qui composent l’entreprise. Les actionnaires ne possèdent que les actifs
de l’entreprise mais ils ne possèdent ni les individus, ni les relations qu’ils entretiennent. En
réalité l’enrichissement des actionnaires ne pourra jamais tenir lieu de stratégie mais sera
une conséquence de la coordination des buts autonomes des individus en un but intrinsèque
cohérent à une entreprise. Celle-ci devra donc formuler une vision et porter des valeurs
auxquelles ses membres pourront choisir d’adhérer. Sans ligne directrice, l’addition chaotique
des intérêts individuels, se fera au détriment de l’intérêt général de l’entreprise, nous y
reviendrons au chapitre suivant.

30 48
SQLI
DIGITAL PERFORMANCE

ENTRETENIR LA DIVERSITÉ
Avant d’aborder les deux propriétés émergentes essentielles d’une équipe agile, la créativité
et la constitution d’une vision globale d’un système informatique, abordons rapidement le
sujet de la diversité. On peut la concevoir comme une forme d’hygiène sociale.

Alors que l’hétérogénéité technologique est souvent perçue comme une source de complications
Ne nous leurrons pas, inutiles (P. Lemberger, 2011), il en va très différemment pour les systèmes vivants. La biologie
créer de la diversité abonde d’exemples qui attestent que la diversité des comportements est le garant de la survie
demande un peu de courage. d’une espèce dans un milieu changeant et hostile. La consanguinité, à l’inverse, est la plus
grave menace. De même, la diversité des profils d’une équipe a été identifiée par différents
auteurs (voir références dans (Appelo, 2010)) comme un facteur de stabilité, de résilience
face aux difficultés dans des situations inédites. Pour autant qu’elles restent dans des limites
raisonnables, les différences de personnalités, de points de vue, de formations, de cultures sont
une source de richesse dans l’appréhension de contextes aussi complexes que ceux des projets
informatiques. Afin d’éviter que les tensions et les débats, que la diversité ne manquera pas de
créer, ne dégénèrent en pugilat puis en explosion stérile, il faudra veiller à ce qu’une majorité
des individus qui composent l’équipe possèdent des aptitudes relationnelles minimales en plus
de leurs compétences spécifiques. Une faible proportion de profils de type « autistes géniaux »
pourra néanmoins s’avérer bénéfique surtout dans des contextes ou la créativité prime avant
toute autre considération.
« Qui se ressemble s’assemble » affirme le dicton. En effet, la plupart d’entre nous avons une
tendance à nouer des relations lorsqu’elles confortent nos convictions, notre légitimité ou nos
aspirations. Ainsi se constituent des microsociétés qui partagent le même jargon, les mêmes
préoccupations et les mêmes plaisanteries. De petits cocons douillets qui tranquillisent leurs
membres mais atrophient leur vision de la complexité du réel.
Ne nous leurrons pas, créer de la diversité demande un peu de courage.

31 48
SQLI
DIGITAL PERFORMANCE

FAVORISER LA CRÉATIVITÉ
La créativité joue un rôle crucial dans l’élaboration des solutions informatiques. C’est elle
qui, hors de tout cadre procédural préétabli, permettra de tenir compte des spécificités d’un
contexte technique et humain pour proposer des solutions innovantes et adaptées. Il en va
pour la créativité comme pour la motivation, un manager ne pourra les créer ex-nihilo à lui
seul. Il peut et il doit cependant faire le nécessaire pour cultiver l’esprit de créativité et pour
cela il doit en comprendre les principaux ressorts.
Les psychologues distinguent trois types de créativité :

La créativité pré-conventionnelle
C’est la forme de créativité qu’on trouve par exemple chez de jeunes enfants qui, pour
résoudre un problème qu’on leur soumet, ont recours avant tout aux images, à l’émotion et à
la spontanéité. Ce mode de créativité fait ​abstraction de toutes les contraintes, qu’elles soient
techniques, scientifiques ou qu’elles relèvent des conventions sociales.

La créativité conventionnelle
Dans ce mode, la pensée est rationnelle mais elle reste dominée par la conscience des
contraintes qui s’exercent sur la solution à imaginer. C’est le mode de pensée conformiste, sans
originalité d’individus rationnels mais sans imagination.

La créativité post-conventionnelle
Surmontant le caractère inhibiteur de la conscience des contraintes, la créativité post-
conventionnelle parvient à imaginer des solutions neuves par associations libres d’éléments
disparates avec l’ingénuité d’un débutant, tout en gardant à l’esprit les contraintes du réel. C’est
le type de comportement que doit viser une équipe agile.

La créativité ne se planifie pas, elle se cultive et s’entretient. Pour entretenir une atmosphère
propice à la créativité, un manager peut prendre quelques mesures de bon sens. La créativité
s’épanouira plus naturellement dans un environnement où règnent franchise et liberté de parole
que dans les atmosphères lourdes où règne l’omerta et où planent les menaces de traquenards.
Un manager peut encourager l’ouverture en créant un environnent où la prise de risque et les
erreurs sont reconnues comme inhérentes aux métiers de l’IT. Parmi les mesures qu’un manager
pourra prendre pour favoriser la créativité post-conventionnelle citons encore l’instauration de
rites de partage d’idées comme des brainstorms ou des séminaires informels ou la mise en
valeur d’individus qui ont fait preuve de créativité.
Rappelons aussi que la routine est l’ennemie de toute créativité, raison pour laquelle une
majorité de démarches agiles préconise d’automatiser autant que possible les tâches
rébarbatives comme le déploiement, l’intégration ou les tests unitaires.

Enfin, toute créativité implique par définition de s’aventurer dans l’inconnu avec une part
inévitable d’inconfort et d’appréhension. Faire en sorte que chacun trouve ici ses bonnes limites
devrait là encore faire part des attributions d’un bon manager agile.

32 48
SQLI
DIGITAL PERFORMANCE

La complexité réside
comme nous l’avons vu dans
les liens et dans les boucles
de rétroactions
(entre individus et systèmes).

FAIRE ÉMERGER
UNE VISION GLOBALE
Dans la vision classique, cartésienne, d’un système d’information, l’activité de modélisation,
qu’elle intervienne en phase de conception ou en amont d’une démarche d’urbanisation,
cherche à construire une vision globale et détaillée d’un système ou d’un projet.

A cet effet, différents modèles sont utilisés, typiquement un modèle par niveau de l’architecture :
l’architecture matérielle, logicielle, fonctionnelle ou encore les processus métiers. De fait,
rares sont les exemples où une telle modélisation complète existe et est maintenue à jour.
L’expérience montre que l’effort à consacrer pour synchroniser tous ces modèles avec
une réalité changeante est le plus souvent irréaliste pour être maintenu sur la durée.
Plus pragmatiques, les démarches agiles considèrent qu’une modélisation globale et détaillée
n’est ni nécessaire, ni même possible. La vision globale n’est en définitive que l’agrégat de
représentations individuelles même si elles sont parfois conflictuelles. En d’autres termes,
c’est une propriété émergente qui appartient à une équipe plutôt qu’à un individu.
Une autre manière de voir vient corroborer ce point de vue. Envisageons un projet informatique
comme un réseau d’individus et de systèmes informatiques en interaction et imaginons
un instant qu’un individu en détienne à lui seul une vision exhaustive. Pour le coup, cela
impliquerait que la totalité de la complexité du système serait contenue dans un seul de ses
nœuds. A l’évidence cette dernière affirmation est fausse puisque la complexité réside comme
nous l’avons vu dans les liens et dans les boucles de rétroactions (entre individus et systèmes).
L’impossibilité pour un individu à détenir une vision globale d’un système dont il est partie
prenante est ce qu’on appelle le Darkness Principle (Appelo, 2010).

33 48
SQLI
DIGITAL PERFORMANCE

Figure 4 :

SYSTÈME D’INFORMATION

100
%

77
%
60
%
49
%
35
%
25
15 20 %
% %

2004 2005 2006 2007 2008 2009 2010 2011

Figure 4 : La vision globale d'un système

complexe émerge des visions individuelles.

Cette dernière observation justifie en particulier que de nombreuses pratiques agiles

préconisent des réunions quotidiennes durant lesquelles les décisions sont prises de
manière collégiale.
La responsabilité du manager est donc de faire en sorte que les équipes prennent leurs
propres décisions, non pas pour des raisons de tactique RH, mais simplement car les décisions
collégiales sont plus lucides puisqu’elles reposent sur une vision plus complète du système.
L’information disponible dans le réseau est plus grande et plus précise que celle contenue
dans chacun de ses nœuds. Paradoxalement mais heureusement, l’abandon par un manager du
contrôle explicite d’une équipe agile apte à prendre ses propres décisions, renforcera son statut
et le contrôle qu’il a d’un projet.

Dans le même ordre d’idées, on voit là encore tout l’intérêt qu’il y a pour un manager à
diversifier les profils dans son équipe puisque la vision qui en émergera sera plus riche que
celle d’une équipe monolithique.

34 48
SQLI
DIGITAL PERFORMANCE

DÉFINIR LES BONNES

CONTRAINTES POUR
CRÉER DE LA VALEUR
COMMENT DÉFINIR DES RÈGLES ?
L’existence de sociétés criminelles, parfois mieux organisées que certains états, démontre
Chaque règle au sein si besoin était que l’auto-organisation n’est pas un bien en soi. Pour qu’un système adaptatif
d’une organisation agile produise de la valeur, encore faut-il que des contraintes et des règles dirigent son évolution
sera élaborée par l’autorité dans une direction choisie. La possibilité de diriger un système social, une entreprise,
un pays ou une équipe de développement dans une direction choisie est la conséquence
compétente la moins de l’existence chez l’homme d’une conscience. C’est elle qui l’a conduit à inventer des lois,
centralisée, la plus petite (en des règles d’éthique, des gouvernements et… le management.
taille) ou celle située
Tout l’art du manager agile consistera à concilier son rôle de facilitateur d’auto-organisation, tel
au plus bas dans qu’il a été décrit au chapitre 4, avec un rôle de créateur de valeur et de régulateur.
l’échelle hiérarchique. Les métaphores du « Jeu de la Vie » et celle des systèmes adaptatifs décrits au chapitre 2
suggèrent une répartition assez claire des rôles pour ce qui concerne l’élaboration des règles
de fonctionnement d’une équipe auto-organisée. L’équipe agile définira elle-même ses propres
règles de fonctionnement pour tout ce qui relève de sa responsabilité de « convertisseur de
savoir en innovation ». Ses membres, supposés compétents et autonomes, connaissent en effet
mieux que quiconque les mesures à prendre pour résoudre les problèmes technologiques et
les questions d’affectation des tâches. Un manager agile appliquera ici le principe
de subsidiarité qui s’énonce ainsi : chaque règle au sein d’une organisation agile sera élaborée
par l’autorité compétente la moins centralisée, la plus petite (en taille) ou celle située au plus
bas dans l’échelle hiérarchique.
Enfin, lorsqu’un manager choisira d’imposer une règle à ses équipes, il motivera ce choix, en
considérant qu’il s’adresse à des individus doués de raison.
Le manager créateur de valeur devra jouer un rôle de régulateur chargé de définir
les contraintes et les incitations propres à créer de la valeur. Selon l’analogie des systèmes
adaptatifs du chapitre 2, il ajustera, non pas les règles qui régissent la dynamique du système
complexe, mais plutôt les paramètres de l’environnement dans lequel celui-ci évolue et élabore
ses propres règles. On distinguera deux grandes catégories de paramètres environnementaux
à gérer par un manager agile : l’établissement d’un contrat social et la définition
d’un objectif partagé.

35 48
SQLI
DIGITAL PERFORMANCE

Accepter de se soumettre
à des règles élaborées par
des personnes n’ayant aucune
connaissance du contexte
projet auquel elles
devront s’appliquer est
une mauvaise idée.

Avant d’aborder ces deux questions, revenons brièvement sur l’élaboration de règles en
général, qu’elles émanent d’une équipe ou d’un manager en charge de son environnement.
L’influence culturelle du célèbre principe de précaution se manifeste parfois par une tendance à
l’accumulation de règles censées anticiper et éviter tous les dysfonctionnements techniques ou
humains imaginables. Expérience faite, l’impact de cette inflation règlementaire est une réalité
doublement néfaste. D’une part l’effort pour mémoriser un écheveau législatif lui fait perdre
toute crédibilité auprès de ceux même qui sont censés l’appliquer car, rapidement, la vérification
de sa mise en application se révèlera illusoire. Ensuite, il en va pour l’excès de législation
comme pour celui des bonnes pratiques que nous avons déjà évoqué, le risque est de créer
un faux sentiment de sécurité qui à son tour déclenche une spirale de déresponsabilisation et
de perte de jugement. Dans le domaine de la sécurité routière par exemple, il a été démontré
que l’ajout de signalisation et de feux rouges peut conduire à une augmentation des accidents
(Spangers, 2007). On préfèrera donc des ensembles resserrés de règles simples du genre : « les
réunions commencent à l’heure », « chaque question posée par un utilisateur exige une réponse
dans la journée » ou « le code doit être mis en gestion de configuration une fois par jour ».
Dans cet esprit, l’élaboration de règles devrait toujours tenir compte du contexte d’un
projet. Accepter de se soumettre à des règles élaborées par des personnes n’ayant aucune
connaissance du contexte projet auquel elles devront s’appliquer est une mauvaise idée.

Les règles élaborées dans d’autres contextes seront considérées plutôt comme des principes
de bon sens que comme des dogmes intangibles.

36 48
SQLI
DIGITAL PERFORMANCE

Un point important pour un

manager qui souhaite faire
respecter certaines règles ou
certaines limites est de les
édicter explicitement.

ÉTABLIR UN CONTRAT SOCIAL

En philosophie politique, l’idée de contrat social désigne un principe d’organisation d’une
société humaine dans laquelle des individus acceptent, pour garantir leur sécurité, de
restreindre leur propre liberté en échange d’un gouvernement chargé de faire appliquer
des lois.
Même si aujourd’hui beaucoup d’entreprises s’apparentent davantage à des mini-aristocraties
qu’à d’authentiques méritocraties, l’idée de contrat social demeure valable même dans ces
contextes, car elle permet de caractériser une relation saine entre un manager agile et ses
équipes. En échange du respect des règles et des contraintes qu’il sera amené à édicter pour
créer de la valeur, un manager agile devra en contrepartie formuler explicitement ce à quoi il
s’engage auprès de ses équipes. C’est là une condition indispensable pour créer un sentiment de
solidarité professionnelle dans lequel pourra s’ancrer la formulation d’un projet commun.

Les attributs du manager agile sont en définitive assez proches de ceux du gouvernement
d’un état de droit et de sa police. Il est chargé d’assurer la sécurité et la liberté de parole de
ses collaborateurs face aux multiples sources de pression, qu’il s’agisse par exemple d’autres
collaborateurs ou de clients de mauvaise foi. Par ailleurs, l’élan auto-organisateur propre à
chaque équipe peut aussi créer des effets de compétition préjudiciables à l’intérêt général
pour tout ce qui concerne l’accès aux ressources partagées d’une entreprise comme les salles
de réunion, les ressources de calcul ou les machines à café. Garantir un accès équitable aux
ressources communes et éviter leur surexploitation font donc aussi partie des responsabilités
d’un manager agile. Un point important pour un manager qui souhaite faire respecter certaines
règles ou certaines limites est de les édicter explicitement.

Les considérer comme implicitement connues ou, ce qui est plus grave, laisser les individus les
découvrir par eux-mêmes, est une solution de facilité qui comporte des risques psychologiques
importants en cas d’infraction par inadvertance. La définition d’une barrière d’autorité qui
énumère des limites claires à l’autonomie ou aux initiatives de chacun, tout comme la définition
d’une notion d’appartenance à une équipe déjà évoquée, sont essentielles car elles contribuent
à l’auto-organisation du système social.

37 48
SQLI
DIGITAL PERFORMANCE

DÉFINIR UN OBJECTIF PARTAGÉ

Parmi les trois catégories de buts discutées au chapitre 4, le but extrinsèque correspond
à l’affectation d’un objectif à une équipe agile par une instance extérieure. Bien qu’un
manager ne soit pas à proprement parler le possesseur de son équipe, il en est néanmoins
responsable et, à ce titre, il est habilité à lui assigner des objectifs qui visent la création
de valeur (plutôt que la création de divertissements technologiques par exemple). Par son
caractère fédérateur, cet objectif contribuera à souder l’équipe le temps d’un projet.

Voici deux objectifs de ce type :

• Objectif de l’équipe A : « Au terme de ce projet, notre maîtrise de HTML 5/CSS 3 pour répondre
aux besoins d’ergonomie et de respect des standards de nos clients ne sera plus à démontrer ».
• Objectif de l’équipe B : « Ce projet doit démontrer la crédibilité de notre équipe
pluridisciplinaire formées d’architectes IT, d’experts métiers et de statisticiens pour aborder les
problématiques Big Data dans un contexte banque-assurance ».

Dans l’idéal, un objectif partagé devrait correspondre à une forme d’intérêt supérieur, à un
motif fédérateur propre à transcender les objectifs individuels. Par conséquent un tel objectif
ne devra en aucun cas être corrélé avec la promesse d’une récompense de type bonus, surtout
à court terme. L’idée est plutôt qu’un objectif partagé, une fois atteint, réponde aux aspirations
profondes des individus : désir de sens, de reconnaissance, de participation à un challenge,
d’utilité pour la communauté, de réalisation de soi, d’exploration des possibles, de travail bien
fait ou de contribution au progrès, pour ne citer que quelques exemples. Que l’atteinte d’un tel
objectif soit nécessairement mesurable n’est pas une condition indispensable en revanche,
contrairement à ce qu’un certain folklore managérial désuet voudrait nous faire croire.

Parmi les innombrables adjectifs que l’on peut associer à un bon objectif retenons-en quatre :
compréhensible, réaliste, spécifique et stimulant.

La prescription d’un certain niveau de qualité est souvent omise des objectifs à atteindre
durant un projet. L’expérience montre pourtant que, laissé à la libre appréciation de chacun, le
niveau de qualité est au mieux imprévisible. Des études révèlent d’ailleurs qu’environ 80% des
individus s’imaginent fournir un travail de qualité supérieure à la moyenne ! Comme les limites
à l’autonomie que nous évoquions précédemment, les objectifs de qualité doivent donc eux
aussi être formulés explicitement par un manager agile.

38 48
SQLI
DIGITAL PERFORMANCE

Naturellement, la définition d’un objectif partagé se pose également au niveau global de

l’entreprise. Des chercheurs en sociologie du leadership ont d’ailleurs montré que parmi les
besoins les plus significatifs propres à entretenir la motivation des équipes figure notamment
l’expression d’une vision par les dirigeants ((Thomas, 2009) cité par (Appelo, 2010)). Faute
d’objectifs clairement formulés, les stratégies individuelles se feront en général au détriment de
l’intérêt de l’entreprise. Progressivement, celle-ci dégénèrera en une aristocratie plus soucieuse
de préserver ses privilèges par le jeu des traquenards politiques que de créer de la valeur pour
l’entreprise. Jurgen Appelo distingue pour ce type d’objectifs d’entreprise deux notions : d’une
part la déclaration de vision et d’autre part la déclaration de mission.

• Formuler une vision de l’entreprise c’est esquisser un projet ambitieux et fédérateur

pour l’avenir. Elle est destinée tout à la fois à inspirer des actions et à guider les décisions
stratégiques.
• Formuler une mission pour l’entreprise c’est dire quelle est sa raison d’être aujourd’hui et
indiquer quels moyens seront mis en œuvre pour réaliser la vision.

La vision comme la mission de l’entreprise devraient lui être spécifique et la démarquer de ses
concurrents. Pour une société de service, un slogan du genre « Tous nos consultants ont l’esprit
de service et ne sont obsédés que par la satisfaction de leurs clients » n’est clairement pas
une vision. Une vision pourrait ressembler à : « Notre société sera d’ici 5 ans la première SSII
100% agile qui intègrera pleinement les principes du management agile aussi bien dans les
relations avec ses clients que dans le management de ses collaborateurs ». Dans l’immédiat,
une déclaration de mission pourrait ressembler à : « Notre ambition est de garantir la qualité de
nos prestations par une spécialisation à un nombre limité de domaines de compétences sur des
sujets d’actualité (cloud computing, Big Data, design HTML 5) et par une veille technologique
active sur ces sujets. »

39 48
SQLI
DIGITAL PERFORMANCE

CRÉER LES CONDITIONS

DE L’AMÉLIORATION
CONTINUE
CHANGER CAR L’ENVIRONNEMENT CHANGE
LE PROPRE D’UN SYSTÈME INFORMATIQUE EST QU’IL
N’EXISTE PAS INDÉPENDAMMENT DE L’ENVIRONNEMENT
POUR LEQUEL IL A ÉTÉ CRÉÉ.
Non seulement les usages, les besoins, les compétiteurs, les technologies et le marché
changent continuellement, mais le système lui-même modifie son environnement, le plus
souvent de manière imprévue. En cas de succès d’un service par exemple, des usages
inattendus peuvent émerger et nécessiter alors des adaptations conséquentes. Tel un organisme
vivant contraint de s’adapter pour survivre dans un environnement en perpétuelle évolution,
un système informatique devra, lui aussi, évoluer faute de dépérir. Maintenir la satisfaction
des utilisateurs à un niveau à peu près constant, sans même parler de l’accroître, nécessite
des évolutions permanentes. Un management agile ne peut donc se contenter de créer de la
valeur « une fois pour toutes ». Encore faut-il assurer que cette valeur perdure au moyen d’une
stratégie lucide d’amélioration continue dans des contextes incertains. Une tâche primordiale
d’un manager agile est donc de faire accepter ce changement permanent à ses équipes, non
pas comme une exception temporaire ou comme une situation transitoire par laquelle il faudrait
passer, mais plutôt comme une caractéristique intrinsèque des projets informatiques et des
organisations agiles.

Comme disait Héraclite : « Rien n'est permanent, sauf le changement. »

La difficulté, nous l’avons déjà évoqué, réside dans le fait que notre culture occidentale et
cartésienne incite beaucoup d’entre nous à voir spontanément dans l’incertitude plus de risques
que d’opportunités. Nous cherchons spontanément une stabilité illusoire dans des contextes
aussi imprévisibles que celui des projets informatiques, là où l’expérimentation et l’acceptation
de l’erreur comme partie prenante d’un processus normal de découverte serait l’attitude la plus
rationnelle.

Un sujet directement lié à l’adaptation continue des systèmes informatiques est la

compréhension des causes qui conduisent progressivement à leur complexification. Pourquoi
un système informatique se complexifie-t-il ? Est-ce inévitable ? Peut-on définir et mesurer

40 48
SQLI
DIGITAL PERFORMANCE

L’adéquation d’un système

informatique correspond à son
aptitude à consommer, dans
un certain contexte, du temps
et/ou de l’argent de certains
individus pour créer de la
valeur pour d’autres individus.

objectivement cette complexité ? Le sujet est vaste et dépasse largement le cadre de cet article.
Très schématiquement toutefois, on peut distinguer deux types de complexité ou plutôt de
complexification au sein d’un SI. Le premier est une complexité que l’on pourrait qualifier d’utile.
C’est celle qui résulte d’une complexification de l’environnement lui-même modélisé, d’une
manière ou d’une autre, dans le système : le nombre de cas d’utilisation d’un logiciel augmente,
le cadre règlementaire dont il faut tenir compte complexifie les règles de gestion à coder, etc.…
Le second type de complexité est la complexité inutile qui résulte d’une maîtrise insuffisante
des technologies, de redondances et de la tendance naturelle à l’augmentation de l’entropie
pour un système sur lequel on n’intervient pas. La quête de simplicité raisonnable doit donc
être active et permanente. Nous pensons qu’un manager agile ne peut faire l’économie d’une
compréhension sérieuse de ces enjeux et renvoyons le lecteur à cet ouvrage (P. Lemberger,
2011) pour une analyse détaillée des causes de complexité inutiles dans un système
d’information et des moyens d’y remédier.
Revenons un instant à l’adaptation d’un système informatique à son environnement. Qui dit
besoin d’adaptation dit, nécessairement, défaut d’adéquation. Mais comment au juste définir
l’adéquation d’un système d’information ? Hélas, il n’y a pas de réponse évidente à cette
question car il n’existe pas d’échelle universelle pour l’adéquation qui en permettrait une
mesure objective. La définir comme la satisfaction des utilisateurs est une possibilité qui vient
rapidement à l’esprit. Pourtant, cette définition laisse beaucoup à désirer car comment évaluer
l’adéquation si seule une fraction des utilisateurs est satisfaite ? Définir l’adéquation d’un
système informatique comme un fonctionnement conforme aux attentes n’est guère satisfaisant
non plus car il est fort possible qu’un système informatique rende pleinement satisfaction alors
qu’il ne correspond à aucune attente préalable. Jurgen Appelo propose quant à lui la définition
suivante : l’adéquation d’un système informatique correspond à son aptitude à consommer, dans
un certain contexte, du temps et/ou de l’argent de certains individus pour créer de la valeur pour
d’autres individus.
Faute de mieux, c’est celle que nous adopterons.
Enfin, un manager agile sera lui-même amené à prendre des décisions dans un contexte
incertain. S’il n’existe certes aucune méthode infaillible pour agir efficacement dans de tels
contextes, les sciences de la complexité fournissent néanmoins quelques analogies suggestives
pour guider l’action dans un environnement mouvant. Ce sera l’objet de notre dernier paragraphe.

41 48
SQLI
DIGITAL PERFORMANCE

L’ART DE LA NAVIGATION
EN TERRAIN MOUVANT
La littérature managériale fourmille littéralement de méthodes d’amélioration continue,
de plans d’amélioration de la qualité et de méthodes de gestion du changement. Pensons
par exemple à la célèbre roue de Deming qui illustre la méthode de gestion de la qualité
« Plan-Do-Check-Act » (PDCA) ou à la méthode Six Sigma, très en vogue actuellement,
qui vise à réduire la variabilité des processus de production.

Figure 5 :

Figure 5 : La roue de Deming. Les cales sous la

roue représentent le principe de non-régression.

Toutes ces méthodes font l’hypothèse, plus ou moins implicite, qu’un système, un processus ou
une organisation peuvent être améliorés progressivement, chaque itération amenant son
lot d’améliorations. C’est précisément ce postulat de linéarité, implicite aux méthodes de
gestion du changement classiques, que les sciences de complexité nous invitent à remettre en
question.

Pour illustrer notre propos, imaginons qu’en dépit des mises en garde de la section précédente,
nous ayons retenu pour le système complexe (par exemple un système informatique ou même
une organisation) une certaine notion d’adéquation (fitness). Imaginons ensuite que l’on puisse
représenter chaque « état » d’un tel système par un jeu de paramètres, vraisemblablement
très nombreux. Le graphe qui représente alors, symboliquement, l’adéquation d’un système
en fonction des paramètres qui le caractérisent est ce qu’on appelle le paysage d’adéquation
(fitness landscape). Le problème d’un manager agile en quête d’amélioration continue consiste
donc à naviguer progressivement vers le maximum global de ce paysage. Deux caractéristiques
de ces paysages d’adéquation de systèmes complexes méritent d’être pris en considération.

1. La recherche a mis en évidence que le degré d’interdépendance entre les composants

d’un système complexe avait un impact significatif sur la forme de ce paysage. Ainsi, il a été
constaté que le maxima global est d’autant plus marqué et aisément identifiable que ce degré
de couplage est faible. Lorsque celui-ci est très fort, on parle de catastrophe de la complexité
car aucun maximum n’est clairement identifiable et tout changement possède des effets
imprévisibles.
2. Contrairement aux paysages accidentés des Alpes qui, eux, n’évoluent que sur des durées
géologiques, le paysage d’adéquation d’un logiciel évolue sur des échelles de temps beaucoup
plus brèves, quelques semaines ou quelques mois tout au plus. Qu’apparaisse une nouvelle
opportunité, un nouveau besoin ou une nouvelle technologie et c’est tout le paysage qui est
chamboulé. Et même correctement identifiés, les pics peuvent alors disparaître !

42 48
SQLI
DIGITAL PERFORMANCE

Figure 6 :

Figure 6 : Le premier paysage d’adéquation

correspond à une situation de catastrophe de
complexité. Le second correspond à une situa-
tion où les différents éléments d'un projet sont
raisonnablement indépendants. Pour parvenir
au sommet il faut cependant changer
de chaîne de montagnes.

Considérons un projet informatique comme un tel système complexe et tirons quelques

conclusions à partir des deux remarques précédentes.
Les composants dont il est question dans la première remarque pourront être identifiés dans
ce contexte à des individus, des outils, des méthodes de développement, des processus, des
langages de programmation etc. On voit donc tout l’intérêt qu’il y a à éviter un couplage trop fort
entre ces éléments qui devraient rester aussi interchangeables que possible, faute de quoi
la « catastrophe de complexité » guette et risque de rendre le projet chaotique.

On constate ensuite l’erreur du postulat de linéarité. Rien en effet ne garantit qu’un sommet du
paysage soit atteignable par itérations successives de petites améliorations. En règle générale,
le chemin vers le sommet comportera des régressions et demandera des sauts qualitatifs pour
rejoindre un camp de base, situé dans la bonne chaîne de montagne, à partir duquel l’ascension
finale pourra être menée. Ces sauts qualitatifs correspondent à des innovations radicales ou
à des changements d’habitudes. Dans une DSI un tel changement pourrait correspondre, par
exemple, au passage d’un modèle de développement planifié à un mode agile. Pour une ESN,
un tel saut pourrait correspondre à une modification du type de contrats avec ses clients :
par exemple le passage d’un mode projet au forfait à un mode plus collaboratif.

Enfin, concernant la seconde remarque, la possibilité de voir disparaître des pics est
naturellement inquiétante mais il existe aussi une reformulation positive de cette observation.
Si le paysage est susceptible de changer inopinément alors, plutôt que d’entreprendre une
longue et incertaine ascension d’un pic lointain et mouvant, essayons plutôt de déplacer
la montagne à gravir ! Déplacer une montagne dans le paysage d’adéquation revient en
l’occurrence à changer les conditions de l’environnement projet. Changer les conditions d’un
projet permet de supprimer des montagnes qui auparavant faisaient obstacle : recruter des
développeurs ou des managers qui viendront soutenir l’instauration d’une démarche agile plutôt
que s’y opposer. L’élément essentiel pour changer l’environnement demeure cependant le désir
même de changer et de s’améliorer. Le rôle du manager est donc de rendre ce changement
souhaitable. Voilà qui nous ramène au sujet de la motivation traité au chapitre 3 : le changement
devient souhaitable dès lors qu’il répond aux motivations intrinsèques des individus : quête de
sens, de compétence, de reconnaissance, etc.

43 48
SQLI
DIGITAL PERFORMANCE

Une autre métaphore tirée de l’analyse des systèmes dynamiques vient corroborer l’analyse
précédente, celle des attracteurs déjà mentionnée au chapitre 2. Rappelons qu’à long terme
un système dynamique non-linéaire se stabilise typiquement autour d’une région bien
déterminée de l’espace des paramètres, l’attracteur. Plus que cela, tous les systèmes dont
le point représentatif se trouve initialement dans un certain bassin d’attraction verront leur
évolution terminer sur l’attracteur associé. Dans les cas favorables, pour un projet informatique,
l’attracteur correspond à cercle vertueux et créateur de valeur, capable de résister aux différents
contextes projets (différents points dans un même bassin). En revanche, cette métaphore
explique aussi pourquoi, hélas, il est souvent si difficile d’échapper à certaines issues néfastes
dans les projets informatiques (non satisfactions des utilisateurs, non respect des contraintes
budgétaires, des délais etc…) et ceci en dépit de toutes les bonnes intentions et des efforts
déployés. Ces efforts, on l’a compris, sont assimilables à des variations de conditions initiales
dans le bassin d’attraction d’un « mauvais » point fixe.

Deux solutions se présentent alors. La première consiste à faire un saut d’un bassin d’attraction
vers un autre, saut qu’on pourra assimiler à la mise en œuvre par une équipe projet d’une
innovation radicale comme par exemple un changement du processus de développement ou
l’utilisation d’une technologie disruptive etc. La seconde consiste plutôt à déplacer ou à faire
disparaître les mauvais attracteurs et leur bassin d’attraction. On pourra l’interpréter comme une
modification de l’environnement du projet : modification des types de contrats avec les clients,
modifications des facteurs d’incitations, changement de business model, prise en compte des
motivations intrinsèques des collaborateurs.

44 48
SQLI
DIGITAL PERFORMANCE

CONCLUSION
LE MANAGEMENT AGILE TEL QU’IL EST DÉFINI PAR
JURGEN APPELO DANS SON OUVRAGE MANAGEMENT 3.0
N’A RIEN D’UNE NOUVELLE RECETTE MAGIQUE ASSORTIE
DE MIROBOLANTES PROMESSES DE ROI.
Plus sérieusement, cette analyse apporte un regard neuf sur le management, ancré dans les
résultats et les concepts des sciences de la complexité. Elle vise à transformer la culture
même du management dans le monde informatique. Son objectif est de mettre en cohérence
les pratiques managériales avec certains aspects fondamentaux des projets informatiques,
liés principalement à leur imprédictibilité, qui restent trop souvent méconnus ou même
carrément niés.

On peut voir le management agile comme une synthèse de deux catégories d’idées appliquées
au management. D’une part, celles des démarches de développement comme Scrum, XP ou
Kanban, qui définissent des rôles, des rituels et des livrables destinés à mettre en œuvre les
principes de l’agilité dans les projets informatiques. D’autre part, les résultats et idées des
sciences de la complexité tels que l’étude des systèmes dynamiques non-linéaires, la théorie du
chaos ou encore les automates cellulaires qui, collectivement, fournissent un riche éventail de
concepts et de métaphores qui permettent de mieux appréhender la dynamique d’un système
aussi complexe qu’un projet informatique.
Ce qui fait l’originalité de cette démarche est qu’elle s’inspire d’autres disciplines qui cherchent
elles aussi, parfois depuis des décennies, à comprendre et maîtriser des systèmes complexes,
au premier rang desquels on citera l’étude du monde vivant, concepteur par excellence de
systèmes à la fois complexes et robustes.
Cette compréhension approfondie nous a permis de définir les quatre responsabilités principales
à assumer par un manager agile : (1) « Favoriser l’autonomie et la compétence », (2) « Favoriser
l’auto-organisation des équipes », (3) « Définir des contraintes pour créer de la valeur » et enfin,
(4) « Créer les conditions d’une amélioration continue ».
Les remises en questions qu’implique ce nouveau paradigme du management sont nombreuses
et profondes. Rappelons quelques exemples :

• Les démarches d’amélioration linéaires, par petits pas, font fi de la nécessité de recourir à des
innovations radicales dans les technologies ou dans l’environnement d’un projet informatique.
• Les organisations hiérarchiques qui fonctionnent en mode « commande et contrôle » sont peu
appropriées à l’élaboration de systèmes complexes et fiables.
• Les méthodes d’incitation classiques telles que les primes ou les bonus ne sont pas des
facteurs de motivation efficaces pour des tâches qui nécessitent créativité, initiative et
responsabilité.

Soyons clair, il ne saurait évidemment être question de faire table rase du passé. Les traditions,
les habitudes et les inerties sont nombreuses et il serait irrationnel de les ignorer. Notre souhait
cependant est, qu’à la lumière des réflexions développées dans ces quelques pages, le lecteur
puisse alimenter sa propre réflexion et contribuer à son niveau à faire reculer un le folklore
managérial au profit d’un peu plus de raison. Tant il est vrai qu’à long terme on ne gagnera
jamais à en différer indéfiniment l’application.

45 48
SQLI
DIGITAL PERFORMANCE

RÉFÉRENCES
• Appelo, J. (2010). Management 3.0 - Leading Agile Developpers, Developping Agile Leaders.
Boston: The Addison Wesley Signature Series.

• Barrand, J. (2007). Le manager agile. Paris: Dunod.

• Brooks, M. (2009, février 4). Born believers: How your brain creates God. New Scientist.

• David Shpilberg, S. B. (2007, October 01). Avoiding the Alignment Trap in IT. MITSloan.

• Ellis, K. (2008). Business Analysis Benchmark. Rapport du cabinet IAG consulting.

• Erich Gamma, R. H. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley Professional.

• Gardner, M. (1970, october). The fantastic combinations of John Conway’s new solitaire game «life». Scientific American,
pp. 120-123.

• Geus, D. (1997). The living Company. Boston: Harvard Business School Press.

• Krigsman, M. (2008, 12, 11). Study: 68 percent of IT projects fail. ZDNET.

• Mentor, O. Agile and XP Object Mentor Success Stories. http://www.objectmentor.com/omSolutions/agile_customers.html.

• Mitchell, M. (2009). Complexity a Guided Tour. New York: Oxford University Press.

• Nonaka, H. T. (1986, jan-fév). The New New Product Development Game. Harvard Business review.

• P. Lemberger, M. M. (2011). Managing Complexity of Information Systems - The Value of Simplicity. Wiley.

• Pink, D. (2011). La vérité sur ce qui nous motive. Paris: LEDUC.S Editions.

• Spangers, C. (2007). Le trafic sans règles est plus sûr. blog.meervrijheid.nl, http://www.meervrijheid.nl/index.
php?pagina=1520.

• Stiegler, B. Prolétarisation. Ars Industrialis.

• Thomas, K. W. (2009). Intrinsic Motivation at Work: What Really Drives Employee Engagement. Berrett-koehler Publishers.

46 48
SQLI Digital Performance
Immeuble le Pressensé
268 avenue du Président Wilson
93 210 La Plaine Saint-Denis
Tél : 01 55 93 26 00
www.sqli.com