Pages

vendredi 20 mars 2015

Ne pas oublier le poids du développement des logiciels


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é.


 Ces écarts ne sont pas le fait du hasard. Il sont liés à la conjonction de différents facteurs dont les deux plus importants comme le montre McKinsey sont :
-      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.