Le développement
de l’économie numérique, des smartphones, des applications mobiles, de l’Internet
des objets,… reposent sur des efforts importants pour créer de nouveaux
logiciels. Ceci représente des milliards de ligne de code à produire. Bien sûr
une partie de ce code est acheté ou obtenu gratuitement mais il est nécessaire
d'en produire une grande quantité. C'est un volume de travail considérable et
on n'a jamais eu besoin d'un nombre aussi élevé de développeurs. Un certain
nombre d’experts avaient annoncé il y a quelques années la fin de la
programmation. Non seulement cela ne s'est pas produit mais on a constaté une activité
de programmation importante.
Dans un des
derniers rapport d'activité de General Electric, Jeffrey Immelt son PDG,
constate que : "Nous croyons que toutes les entreprises industrielles
deviendrons des entreprises de logiciel (software compagny)". On estime
que 40 % des produits et des services sont aujourd'hui consommés reposent sur
du logiciel. Ce nombre a doublé ces 20 dernières années.
Dans ces
conditions la performance et la qualité de ces logiciels sont des facteurs de différenciation
des entreprises. Effectivement on observe que dans le même secteur certaines
firmes réussissent à développer des applications efficaces et performantes
alors que d'autres éprouvent de graves difficultés. Il est certain que la
capacité des entreprises à assurer des développements rapides et importants est
un facteur de différenciation des organisations. Il y a celles qui maîtrisent
ces opérations et celles qui n'y arrivent pas.
Toutes les entreprises ne sont pas égales
Il existe en matière
de capacité développement des différences significatives entre les entreprises.
Pour les mesurer McKinsey à effectuer une enquête ([1]) qui fait apparaîtra des
écarts importants entre les entreprises :
- La
productivité des développeurs mesurée par le nombre d'unité de complexité
produites par personne et par semaine. Elle varie entre le premier et le
dernier quartile de l'indice 53 à 175 sachant que la moyenne est de 100. Cela
représente entre les bons et les moins bons un écart de 230 %.
- Le
volume de code produit est mesuré par le nombre d'unité de complexité produites
par semaine. L'écart constaté entre le quart des équipes les plus performantes
et celles qui le sont moins est de 293 % (indice 224 contre 57). Deux équipes
de même taille devant faire le même travail, l'une produit son code quatre fois
plus vite que l'autre !
- La
qualité du code est mesuré par le nombre de défauts de conception résiduel.
L'écart est encore plus impressionnant. On va de l'indice 27 à 155 soit un
écart de 474 %, soit près de six fois plus de bugs pour la même taille de code !
Ces chiffres
montrent qu'en matière de développement toutes les entreprises ne sont pas sur
le même plan. On notera que ce ne sont pas des écarts de quelques pourcents
mais de plusieurs centaines de pourcents. Cela veut dire que les entreprises
ayant des équipes de développement performantes sont capables de sortir des
produits ou des services plus vite et moins chère que les autres. De plus le code qu'elles livrent
est de meilleur qualité.
- Le
positionnement des développeurs dans l'entreprise. La plupart du temps ils sont
regroupés dans des équipes d'études dépendant de la direction informatique. Ils
sont donc loin des décideurs de l'entreprise. Ceci explique leur difficulté à
comprendre ce que les dirigeants attendent d'eux et réciproquement ceux-ci ont
du mal à suivre leur logique. Ce sont deux mondes différents.
- Très
peu de dirigeants sont compétents en matière de développement. La plupart des
DG sont d'anciens responsables financiers ou commerciaux. Il n'ont qu'une
vision lointaine des développements informatiques. En dehors des patrons des
sociétés de services et des éditeurs de logiciels rares sont les décideurs
connaissant l'informatique.
Dans ces
conditions on comprend mieux les disparités des résultats constatées entre les
équipes de développement. Ceci fait qu’elles sont souvent laissées à elles même.
Elles fonctionnent bien ou mal selon les orientations fixées par les initiatives
des responsables d'équipes de développement.
Des décisions difficiles à prendre
Compte-tenu du
développement rapide de l’économie numérique et surtout la transformation
numérique des entreprises les dirigeants vont devoir prendre dans les années à
venir de nombreuses décisions dans ce domaine :
- Quels
projets choisir ? Parmi les nombreuses demandes effectuées quels sont
celles qui sont prioritaires ?
- Quelle
solution adoptée ? Pour traiter un besoin donné il existe toujours plusieurs
solutions possibles. Laquelle choisir ?
- Faut-il
faire ou faire-faire ? A-t-on les moyens de piloter et de contrôler efficacement
les travaux sous-traités ?
- Comment
organiser les opérations ? Que faut-il traiter en premier ? Dans quel
ordre les opérations sont lancées ?
- Comment
évaluer la qualité des développements effectués ?
- ....
De manière plus
générale comment une entreprise s’y prendre pour lancer rapidement et
efficacement une nouvelle activité si on n’a pas la moindre idée des
développements informatiques à effectuer. De plus comment s’y prendre si on ne
connait pas l’art et les techniques du développement informatique. Comme on le
voit ce ne sont pas des problèmes techniques mais des choix de management./
Confusion et gabegie.
Ainsi une grande
entreprise décide de mettre a la disposition de ses clients une application web
permettant de suivre l'avancement de leurs opérations avec l'entreprise. Comme cette
application concerne presque toutes les unités de l'entreprise le projet est
pris en mains par le directeur général adjoint. Mais très vite il constate qu’il
a du mal à organiser les opérations. Il ne fait pas de planning et établi un
vague budget. Il décide de confier les développements à deux équipes
différentes, une interne et l'autre externe. Très vite des conflits de
frontières apparaissent entre les équipes. Chacune attend l'autre. Les codes
livrés sont incompatibles entre eux. Finalement il faut deux fois plus de temps
pour livrer une application qui s'avère fragile et difficile à utiliser par les
clients. Après un an suivant la mise en production on constate que très peu de
clients utilisent l’application. Elle est utilisée en interne pour répondre aux
questions des clients posés par téléphone ou par mail.
En fait, ce
dirigeant a commis sans le savoir trois d’erreurs fatales pour le projet :
- Sous-évaluer la complexité de l’opération à
mener. Il a raisonné comme sil s’agissait d’une opération simple. Il a
imaginé que sa mise en œuvre se ferait en « un clin d’oeil ». De ce
fait il a sur-délégué aux équipes ce qui relève de sa responsabilité, notamment
la définition du cadre de travail.
- Oublier le planning et le budget. La
gestion des délais est au cœur de la gestion de projet. La difficulté à
identifier les opérations à effectuer et l'ordre dans lequel elles doivent être
faites rend délicate la détermination du planning et du budget de
l'opération.
- Incapacité d’évaluer la qualité ou plutôt
les non-qualités produites. N'ayant pas établi de spécifications claires il
a été impossible de les valider. Il est plus difficile de s'assurer de la
conformité des livrables de l'application à ce qui a été demande.
Ces trois
facteurs sont la conséquence directe du manque de culture projet du décideur.
La gestion de projet est peu enseignée aux futurs dirigeants (énarque,
polytechniciens, centraliens,…). Les dirigeants se sont souvent formés à ces
techniques sur le tas et très fréquemment ils n'ont qu'une connaissance limitée
de ces techniques. Ils sont encore plus ignorants des méthodes de développement
informatiques utilisées.
Foncer dans le mur en klaxonnant
Deux cas délicats
permettent d’apprécier la difficulté de ces opérations :
- Lancement d’un service de commerce en ligne
dans plusieurs pays. Une entreprise de distribution décide de lancer un
service de commerce électronique dans plusieurs pays européens. Le contenu des
catalogues n'est pas identiques d'un pays à l'autre, les textes de présentation
sont des langues différentes. Ils doivent être traduits et adaptés au contexte.
De plus certains pays sont multilingues (Belgique, Suisse, …). Les prix et les
coûts d’expéditions sont différents d’un pays à l’autre. De même les taux de TVA
sont différents et les modes de paiement ne sont pas les mêmes. Certains pays n’utilisent
pas l’euro et ont des monnaies spécifiques comme la Grande Bretagne. Face à la
complexité du système le directeur marketing décide de simplifier le problème
et réalisant d’abord une version française puis d’en dériver les différentes
versions spécifiques à chaque pays.
Mais
après quelques mois la charge de maintenance explose. Le décideur marketing
n’avait pas vu que lorsqu’on effectue une modification sur une des 15 versions
il est nécessaire d’aller modifier et tester les 14 autres versions. Très vite
cela devient non-maîtrisable.
- Récriture d'une application de tenu de
comptes bancaire. C'est une ancienne application qui traite quotidiennement
de très gros volumes d’opérations. Depuis de nombreuses années elle rencontre des
problèmes de performance. Il est vrai que la solution existante est
rustique : Cobol et séquentiel indexé. Le directeur général décide que cela
ne peut pas durer et que cette application doit réécrite en C avec une base de données
relationnelle. Cela parait simple et le développement doit être réalisé en 6
mois. Au lieu de cela il va traîner pendant 3 ans. Ceci est dû au fait qu’au moment
du lancement du projet presque aucun développeur de l’entreprise ne maîtrisait
le C et la base de données choisie. Le résultat n'est pas brillant. Le
traitement quotidien dure 50 heures au lieu de 2 heures. De plus l'application
est instable. Ceci fait qu'après beaucoup d'effort l'application n'est pas mise
en production.
Dans ces deux cas
les difficultés rencontrées se rencontrent de temps à autres mais elles ont été
aggravées par le manque de connaissance des décideurs qui sont appelés à arrêter
les grandes orientations concernant le projet. Ils font des choix inconséquents
et ensuite ils ont beaucoup de mal à suivre les opérations pour corriger les
dérives qui surviennent. C’est la logique du bateau ivre sans capitaine.
Rôle de la gouvernance des Systèmes
d’Information
Dans ces
conditions que peut-on faire ? Mettre à côté des décideurs des experts
chargés de les prévenir des difficultés potentiels ? Promouvoir des
dirigeants compétents en matière de développement de logiciels ? ...
Va-t-on aller jusqu'à nommer une personne représentant les développeurs au sein
du comité de direction ? Ou, à l’inverse un membre de la direction
générale responsable de l’ensemble des développements informatiques ?....
La solution est
simple. Elle repose sur le développement de la gouvernance des systemes
d'information. Il ne s'agit pas seulement d'appliquer les règles de la
gouvernance à l'informatique ([2])
mais d’avoir une vision plus générale concernant l'ensemble des systèmes
d'information.
Ces règles s'organisent
selon trois grands axes :
- Développer l’excellence parmi les
développeurs. Il s'agit de lutter contre la sclérose naturelles des
professionnels. Cela se fait en jouant sur les recrutements, la composition des
équipes et le développement de l’émulation entre elles. Faut-il aller jusqu'à
developper la compétition entre les développeurs ?
- Améliorer le niveau de compétence en
système d'information des décideurs. Ce n’est pas simple car ce savoir
évolue très vite. Il ne s'agit pas de transformer les membres des comités de
direction en informaticiens mais de leur donner les moyens de comprendre les
enjeux et de prendre les bonnes décisions et, en cas de dérive, de savoir ce
qu'il est possible de faire pour faire cesser ce processus.
- Nécessité de renforcer la culture projet
des entreprises. Il est assez étrange de constater que la gestion de projet
est peu enseignée dans les Grandes Ecoles et dans les Universités. Vingt ans
après quand les étudiants sont devenus des décideurs ils se trouvent très
désarmés face à des développements complexes. Cela peut mener à de sérieuses
difficultés voir à de véritables plantages.
Il y a quelques
années on avait cru que la solution consistait à mettre en place des maitrises
d’ouvrage. Comme on les trouvait un peu faible on les a renforcées avec des
assistants à maîtrise d’ouvrage. Puis on en mis en place des maîtrise d'ouvrage
professionnelles à plein-temps. On s’est alors aperçu que c’était lourd et surtout
que cela ne permettait pas de briser le mur de verre entre les décideurs et les
professionnels des systèmes d’information, tout au plus cela le déplaçait.
Pour y arriver il
est préférable de chercher à développer les bonnes pratiques de matière de
gouvernance des systèmes d’information. Elles concernent quatre domaines :
Au total 98
bonnes pratiques ont été recensées. Tous ces domaines sont concernés en
particulier celui s'intéressant à la conception des systèmes d’information.
Parmi ces 25 bonnes pratiques identifies trois sont particulièrement
importantes. Ce sont :
« 10. Désigner un responsable du
système d'information. Il est nécessaire qu’une personne soit responsable
de la conception du système d’information et ensuite de son fonctionnement. Ce
peut être la même personne mais souvent ce sont deux personnes différentes.
Souvent on nomme un responsable hiérarchique mais on peut aussi confier cette
charge à un responsable fonctionnel. Pour être efficace il est nécessaire qu’il
ait la responsabilité de l’ensemble du système d’information et pas seulement
d’une partie. »
« 3. Accorder une grande
importance de l’organisation. L’efficacité du système d’information dépend
pour une grande partie de la qualité de l’organisation mis en place. Elle
comprend différents types de travaux :
-
l’identification des tâches, leur regroupement, leur suppression, leur fusion,…
-
la répartition des tâches entre les différents intervenants,
-
l’efficacité des contrôles mis en place,
-
le développement des compétences du personnel,
-
la formation des intervenants,
-
…
La
qualité de la conception de l’organisation est un facteur clé de l’efficacité
des systèmes d’information. »
« 9. Partir de l’existant et le faire
évoluer. La plupart du temps la conception du nouveau système d'information
se fait à partir d’un système informatique et une organisation préexistante. Il
est donc important de commencer la conception du futur système d’information
par une analyse de l’existant faisant apparaître les points forts et les points
faibles. Ensuite en tenant compte des menaces et des opportunités les
concepteurs du système d’information vont définir la manière de le faire évoluer. »
Si ces trois
bonnes pratiques sont appliquées le niveau des risques inhérents à tout projet
de système d'information diminue de manière significative. Mais toutes les 22 autres
règles sont importantes et devrait être appliquées. Pour apprécier le niveau de
maturité d’une entreprise en matière de systèmes d’information (conception,
fonctionnement, pilotage, évolution) il suffit de compter le nombre de celles
qui sont réellement mises en œuvre. Sur la petite centaines de bonnes pratiques
combien sont réellement opérationnels : 20, 50 ou 80 ? Le test est
rapide et sans pitié.
[1] - "The perils of ignorant software
development", Péter Andén, Changera Gnanasambandam et Toi Stràlin,
McKinsey Quarterly, February 2015.
[2] - Le CobiT existe depuis
maintenant 20 ans (en effet la publication de sa première version date de 1996).
Depuis cette date des progrès importants ont été réalisés en matière de
gouvernance informatique. Mais on constate qu’en matière de gouvernance des
systèmes d’information les progrès sont beaucoup plus lents.
