Il est parfois des livres ou des articles qui parviennent à mettre des mots sur des idées qui vous travaillent sans pouvoir toujours les exprimer clairement. C’est le cas de l’excellent article de Cecil Dijoux intitulé “La DSI désintégrée face à la digitalisation de l’entreprise”, paru en août 2014 dans La Revue du Digital.
L’auteur y combat quelques mythes, bien ancrés dans l’esprit de beaucoup de dirigeants et de leurs DSI, mythes entretenus depuis des décennies par des armées de consultants tous pareillement formatés. Ces mythes expliquent pour beaucoup pourquoi nos entreprises françaises sont si désarmées et inefficaces face à la digitalisation ultra rapide, pendant que les géants de l’Internet (pour la plupart américains) innovent et croissent joyeusement sur la vague de cette digitalisation.
Premier Mythe: l’externalisation
“En conseil stratégique, l’orthodoxie fait l’hypothèse que l’externalisation va permettre à la DSI d’améliorer sa performance et de mieux gérer ses coûts.” C’est un des mythes les plus répandus et une des racines du mal. Il faut ainsi externaliser son helpdesk, la maintenance de ses applications (TMA), l’exploitation de ses applications (infogérance), mais aussi leur développement (offshore) et tant qu’on y est toute sa stratégie informatique (schémas directeurs).
Tous ces concepts sont familiers, nous les avons entendus et vus à l’œuvre si souvent. Pourtant, “même dans le cas où les coûts diminuent (ce qui reste à confirmer), ces calculs prennent rarement en compte les délais qui s’allongent et, mécaniquement, la satisfaction du client qui s’effondre” car alors “chaque transaction, chaque passage de relais devient contractuel”.
La DSI ne devrait se réduire qu’à une entité chargée de sélectionner des fournisseurs, négocier des tarifs avec la direction des achats et passer des bons de commande ?
Second Mythe: on n’a besoin que de chefs de projets
Cecil Dijoux se pose cette question qu’on est amené à se poser fréquemment dans nos DSI: “pourquoi n’a-t-on plus que des chefs de projet dans nos organisations informatiques ?”
C’est bien entendu le résultat de la politique d’externalisation, mais cela dit aussi beaucoup de la hiérarchie des valeurs qui a cours dans ces organisations traditionnelles. Elle répond souvent au schéma suivant (dans lequel j’ai volontairement inclus les termes de MOA et MOE que j’ai bannis de mon vocabulaire quotidien):
C’est un type d’organisation qu’on retrouve dans toutes les DSI de grandes sociétés françaises: le haut de la pyramide est constitué d’employés de l’entreprise, tandis que le bas est confié à des sous-traitants, que ce soit en assistance technique ou au forfait.
Le message sous-jacent est simple: l’activité de développement n’a pas de valeur ! on n’a pas besoin de l’avoir en interne, il suffit d’avoir les gens qui vont contrôler les développeurs. Quant à ces derniers, on va les acheter au moins disant sur le marché, en utilisant les services et les techniques de la direction des achats…
Troisième Mythe: les centres de service
Encore un modèle qui fait florès, parce qu’il parait logique et naturel: regroupons les équipes par domaine de compétence, “pour une meilleure efficacité”. Par exemple:
- créer un centre de service BI, regroupant tous les experts de la société. Mieux encore, confions ce centre de service à une société externe (externalisation encore)
- créer un pôle de chefs de projets pour centraliser le pilotage et uniformiser les méthodes.
- mettre en place un grand pôle de développement (“centre de solutions”) en charge des projets de tous les métiers.
On le sait depuis que les “méthodes agiles” ont prouvé leur efficacité, et depuis que les géants du Web ont montré leur capacité à garder un rythme d’innovation important, les modèles qui marchent sont ceux d’équipes de taille réduite et pluri-compétences (métier, développement, tests, …), tout l’inverse d’une démarche en centres de service. On connait bien leurs défauts: démarche client/fournisseur au lieu de coopération, structures orientées vers elles-mêmes plutôt que vers la fluidité de l’expérience des utilisateurs, corporatisme (“c’est pas mon métier de faire des tests”), modèle “waterfall” plutôt que agilité, etc…
Dans mon équipe, j’ai longtemps parlé de “dé-taylorisation” pour expliquer ma démarche visant à dégonfler les organisations par métier pour passer à des équipes pluri-disciplinaires.
Quatrième Mythe: uniquement des solutions de marché
En voilà un qui a la vie dure: comme l’écrit Cecil Dijoux “personne ne s’est jamais fait licencier pour avoir acheté du « mettre ici le nom_d’un_grand_éditeur_de_logiciel_d’entreprise. »”, plus connu sous la forme “Nobody gets fired for buying IBM”.
Selon ce mode de pensée, sont à bannir les logiciels libres (absence de support) ou le développement interne (pas notre métier). Selon Cecil Dijoux, derrière ces arguments rationnels se cachent en fait des stratégies de survie des DSI (“il vaut mieux avoir tort avec tout le monde que raison tout seul”). Je le rejoins tout à fait sur cette analyse.
Tout faux
Dans un monde qui se digitalise à grande vitesse, quel que soit le métier, ces stratégies ont tout faux. Il suffit de se tourner vers les Google, Amazon, Facebook et autres Twitter ou Linkedin, pour voir que ces sociétés n’appliquent aucun de ces principes.
| Approche traditionnelle | Approche “digitale” |
| Externalisation du développement | Equipes intégrées, agiles et pluri-disciplinaires. Logiciel maison au coeur de la stratégie de l’entreprise (ex: gestion logistique complètement spécifique chez Amazon) |
| Pas de développeurs en interne | Les développeurs sont les ressources les plus critiques et les plus recherchées, les sociétés se disputant les meilleurs. |
| Infogérance des applications | Gestion en interne, appropriation totale de la qualité de service. Démarche “Devops” qui intègre l’exploitation dans les équipes de développement |
| Solutions du marché | Recours systématique à l’open-source. Mieux: partage en open-source des innovations développées en interne (un des facteurs qui a permis l’émergence du Big Data, les éditeurs traditionnels n’ayant été que des suiveurs). |
| Schéma directeur, schéma d’urbanisme du SI | Développements sous forme de micro-services indépendants, gérés par de petites équipes autonomes, atteignables sous forme de services web. |
| Cycle de développement long et peu agile | Mises en productions fréquentes (semaine), ultra fréquentes (jour) voire en quasi continu (plusieurs dizaines de fois par jour) |
On pourrait étendre la liste à l’envie.
Une conviction
Il faut bien le reconnaitre, ces stratégies du passé et ces réflexes de survie sont bien souvent le fruit d’un manque de conviction et de passion de certains dirigeants quant à ce qui devrait être le coeur de leur métier: l’informatique, les réseaux, bref la technologie. Trop souvent on a affaire à des dirigeants qui pourraient tout aussi bien être en charge d’une usine de sauce tomate ou d’un centre des impôts…
Pourtant le digital, c’est d’abord de la technologie et des hommes et femmes passionnés de technologie. Des développeurs, rois de la situation, des “digital natives”, etc…
Pour moi, ma conviction est faite: la voie à suivre pour digitaliser nos entreprises est celle qui met la technologie au centre: avoir les meilleurs développeurs, maitriser son avenir en développant son coeur de métier, adopter les méthodes de travail réellement agiles, une voie qui sort “par le haut”, qui a de l’ambition et qui motive les équipes.
Même si ça peut paraître dingue, la voie est tracée par les Facebook, Google et autres: courrons derrière eux !
![Transcend TS8GSDHC10E Carte mémoire SDHC Classe 10 8 Go [Emballage « Déballer sans s'énerver par Amazon »]](https://images-na.ssl-images-amazon.com/images/I/41v5MQEGEbL._SY100_.jpg){kind=small}
son, en famille, un outil bien connu des équipes de développement “agiles”: un kanban.
Quatre colonnes, autant de lignes que de personnes et des règles simples:
