Vite ! Mon système de management doit changer

A la fin du XXe siècle, les services informatiques et les SSII ont cherché à adopter les principes du Taylorisme pour accroitre leur productivité. Cela sans prendre en compte les particularités que constitue le domaine du service. Après l’âge d’or de l’informatique toute puissante, l’évolution du marché et des exigences des utilisateurs, ces mêmes acteurs se retrouvent dans l’obligation de changer leur système de management.

Afin de mettre en application les principes de Kotter sur la conduite du changement, je vous propose, dans cet article, d’appliquer le 1er principe et de mettre en évidence l’urgence du besoin de changement dans le système de management communément rencontré dans l’informatique.

Le Taylorisme

Le Taylorisme s’articule autour d’un ensemble de principes :

1. La division verticale du travail.
   Le travail est découpé en 2 grandes activités, le travail d’exécution et le travail intellectuel de conception. Ainsi, les personnes qui réalisent sont privées de toute initiative. Ils doivent se plier à la façon de réaliser, aux procédés utilisés, à l’organisation, et au rythme de réalisation donné par l’autre groupe de personnes, dont le travail est de trouver de façon scientifique (sans la moindre pratique) la meilleure façon de faire.
2. La division horizontale des tâches.
   Au niveau de la réalisation, toutes les activités sont découpées en tâches élémentaires qui sont données à réaliser à des personnes dont l’objectif est de traiter le plus efficacement possible ce type de tâche. Chacune de ces tâches devant être réalisée avec un minimum d’interaction. Ce procédé amène à l’ultra-spécialisation des personnes qui ne savent alors plus réaliser qu’un seul type d’activité.
3. Le contrôle dissocié.
   Les activités de contrôle ne font pas parties de la production et doivent donc être réalisées indépendamment par des personnes différentes.
4. Salaire au rendement.
   Conscient du caractère abrutissant et démotivant de ce découpage, Taylor introduit la rémunération au rendement pour lutter contre ce qu’il appelle « la flânerie ouvrière »

Ce mode d’organisation s’est très fortement développé dans l’industrie de 1910 à 1970, ce qui a eu de forts impacts sur la structuration du management.

• Concentration de toutes les initiatives sur un groupe restreint de personnes ;
• Renforcement de la hiérarchie ;
• Valorisation des travailleurs « intellectuels » par rapport aux travailleurs « manuels » ;
• Développement du micro-management ;
• Diminution de l’autonomie ;
• Gestion de la motivation par l’argent ;
• Plan de formation favorisant la spécialisation ;
• Définition des processus de travail dissociés de la production.

Le Taylorisme et l’informatique

Depuis mai 68 et la révolte des OS au début des années 70, l’application des principes du Taylorisme est en perte de vitesse dans l’industrie. Pour autant, le Taylorisme n’est pas mort. Depuis les années 80 il a progressé, sous des formes modifiées, dans le secteur des services et en particulier dans les services informatiques, porté par des promesses de gains de productivité, et par les contraintes induites par l’offshorisation croissante de projets informatiques.
Petit retour d’expérience :

Pour illustrer la mise en place des principes de Taylor dans l’informatique, je vous propose de décrire l’organisation d’un projet auquel j’ai participé. Cette expérience a été pour moi le facteur déclenchant qui m’a fait comprendre l’urgence de changer notre système de management.

En 2005, alors que je travaillais pour une grosse SSII, j’ai eu l’occasion de participer à un projet au forfait de plusieurs dizaines de millions d’Euros. L’organisation de ce projet était conforme aux préconisations de Taylor :

Une équipe de « cols blancs » d’une dizaine de personnes

• Des chefs de projets
• Des architectes / experts technique (dont je faisais partie)
• Des analystes fonctionnels

Une équipe de « cols bleus »  d’une cinquantaine de personnes

• Développeurs front
• Développeurs back
• Développeurs éditiques
• Développeurs base de données / ETL
• Développeurs de maintenance
• Testeurs

Dans ce contexte, l’équipe fonctionnait de façon Taylorisée. L’équipe d’architectes avait définie en amont les bonnes pratiques, les outils, la façon d’écrire le code pour chaque cas qui devait se présenter. Les chefs de projets organisaient le travail en donnant les tâches à faire aux développeurs qu’ils jugeaient les plus compétents pour les réaliser, tout en en leur imposant le temps nécessaire pour la réalisation. Les analystes définissaient les besoins en donnant tous les algorithmes pour les règles de gestion. Les développeurs quant à eux n’avaient qu’à appliquer les règles pour traduire les algorithmes en code sans comprendre comment leur réalisation s’intégrait dans la globalité du projet. Ces mêmes développeurs étaient sous surveillance constante de leurs multiples hiérarchies, des chefs de projets pour la surveillance du temps de réalisation, des architectes pour la surveillance de l’application des recommandations, des analystes pour la surveillance des réalisations fonctionnelles.
Toute cette organisation, pourtant très classique dans les projets informatiques, ne fonctionnait pas. Les retards s’accumulaient, la qualité était catastrophique, les développeurs étaient insatisfaits et n’avaient qu’un seul objectif : qu’on les sorte du projet. Face à toutes ces difficultés, aucune remise en cause de l’organisation n’a été faite. La faute en incombait aux développeurs sur lesquels toute la pression retombait.

Avec le recul, je pense que le manque de communication et de connaissance des personnes dans les différentes équipes était la cause principale de cet échec. En effet, les préconisations techniques et les processus utilisés (dont j’étais un des prescripteurs) ont été faits sans tenir compte du contexte réel du projet. Nous n’avons pas donné la parole aux équipes de développement, qui étaient très juniors, et nous leur avons imposé des façons de faire trop complexes, qu’ils avaient du mal à appréhender. Le découpage du travail en micro-tâches et leur affectation arbitraire qui était faite par les chefs de projet posait des problèmes de qualité, car les développeurs ne comprenaient pas le fonctionnel de ce qu’ils réalisaient. Ce manque de compréhension globale et le manque d’autonomie laissé aux équipes induisaient de plus une démotivation forte, et par conséquent une baisse de la productivité et de la qualité.

Pourquoi est-il urgent de changer ?

Le taylorisme est un système de production rigide. Un changement dans les produits ou dans les méthodes de production implique de repenser tout le découpage des tâches. Il n’est donc pas adapté à une demande changeante, et à des produits diversifiés.

Pour lutter contre cette contrainte, depuis les années 80, les sociétés de service informatique cherchent à s’industrialiser, à faire en sorte que projet après projet, on puisse réutiliser les façons de faire, les outils, et l’organisation. Pendant longtemps, l’informatique toute puissante a cherchée à imposer au métier de ses clients des procédures et des façons de faire. Non pas dans le but de rendre le meilleur service, mais dans celui de réutiliser des concepts industrialisés, disponibles sur étagères.

Pourtant, le constat est que l’on ne fabrique pas un logiciel de la même façon que l’on produit des voitures à la chaine. Chaque produit logiciel doit disposer de ses fonctionnalités phares, d’un positionnement bien précis. Ce dernier ne sera généralement produit qu’une seule fois, contrairement au mode de production industriel. Le propre du service est de comprendre et de s’adapter à la demande du client. L’ère industrielle avait pour objectif la production de masse de produits identiques. L’ère du service repositionne le client et sa demande au centre du besoin.

De plus, aujourd’hui le secteur de l’informatique est de plus en plus complexe et changeant :

• La durée de vie d’un logiciel est de plus en plus courte ;
• Le besoin des clients de plus en plus changeant ;
• Les technologies évoluent de plus en plus rapidement ;
• Les domaines touchés sont de plus en plus larges et complexes.

Avec l’émergence du Web et des terminaux mobiles, le développement grandissant d’applications grand public fait revenir au 1er plan des domaines qui autrefois étaient sous-estimés :

• L’ergonomie des applications ;
• Le design graphique ;
• L’expérience utilisateur ;
• La qualité.

Dans ce milieu de plus en plus changeant et concurrentiel, les sociétés de service informatique et les DSI doivent donc réagir et adapter leur organisation et leur management pour être en mesure de coller au plus près à l’ensemble de ces contraintes. Pour cela, il ne faut pas oublier que dans le secteur du service, le premier facteur de réussite est la satisfaction du client . C’est à cette seule condition que les contrats et les projets pourront être reconduits, que des mises en concurrence pourront être évitées, et que le bouche à oreille pourra fonctionner de façon positive. Pour cela, on ne peut plus rester sur les principes Tayloristes, trop rigides, nous devons trouver d’autres modes de fonctionnement permettant de retrouver la productivité, le sens du service, et l’écoute du client indispensable pour se démarquer et faciliter une bonne croissance dans ce milieu.

Et après …

Une fois le constat de la nécessité de changer établi, il faut trouver une vision pour ce changement. Vers quoi devons-nous évoluer pour répondre aux problèmes d’organisation et de management qui se posent à nous ?

La réponse à cette question est complexe, et en aucun cas unique. Elle doit prendre en compte à la fois des principes d’organisation et de management. De nombreux auteurs se sont penchés sur ce problème. Ils abordent l’entreprise sous la forme d’un système adaptatif complexe qui se trouve en mouvement constant. Pour avancer, l’entreprise doit prendre en compte le potentiel humain qui constitue sa principale plus-value, en apprenant à motiver des hommes et des femmes, pour décupler leur potentiel en ainsi gagner en créativité et en productivité.

Dans son livre « Management 3.0« , Jurgen Appelo aborde une approche moderne du management des équipes qui  doit évoluer vers une meilleure gestion de l’humain et de la complexité globale des interactions dans les organisations. Pour cela, il convient de valoriser quelques principes clés :

• La vision et les valeurs de l’entreprise
• La communication entre les acteurs
• L’auto organisation des équipes
• L’autonomie et la délégation
• La motivation intrinsèque
• L’amélioration continue

Couplés à une organisation Agile , ces principes de management sont la clé pour être en mesure de gérer la complexité et les exigences croissantes qui pèsent sur l’informatique.

Aujourd’hui de plus en plus d’entreprises expérimentent avec succès de nouvelles façon de voir l’entreprise. Parmi celle-ci nous pouvons citer :

• Spotify avec son organisation en en Feature Team,
• FAVI qui a construit son système de management autour du précepte « L’homme est bon »,

Dans son livre « Reinventing Organizations », Frédéric Laloux présente une étude portant sur de nombreuses autres organisations ayant fait le choix du changement. Il présente lui même son livre lors d’une conférence visible sur le web.

L’étude de ces principes dépasse largement le cadre de cet article, ils seront présentés de façon détaillée par la suite, dans des articles dédiés.

De la même façon,  Xebia, conscient de la nécessité de ce changement, essaie de nouveaux modes de management en interne. Nous vous parlerons aussi dans un prochain article de cette nouvelle façon de penser le management que nous avons implémenté chez Xebia.

Pour aller plus loin