OU VA LE LOGICIEL OPEN SOURCE ?Stéphane Kimmerlin et Habib Guergachi

OU VA LE LOGICIEL OPEN SOURCE ?
Stéphane Kimmerlin et Habib Guergachi

Stéphane Kimmerlin, Responsable Stratégie, Division Développeurs et Plate-forme d’Entreprise de Microsoft

Habib Guergachi, Directeur Associé de Zenexity

* * * A l’occasion de Solution Linux, ITRmanager a confronté les points de vue de deux experts sur l’évolution des logiciels Open Source et traditionnels et sur leur positionnement respectif.

1E PARTIE
LES LOGICIELS LIBRES : DES COUCHES BASSES VERS LES COUCHES HAUTES. On dit couramment que les logiciels libres sont mûrs au niveau du système d’exploitation, de l’infrastructure, du middleware et qu’au fur et à mesure que l’on s’élève dans les couches, ils le sont de moins en moins. Qu’en pensez-vous ?

Habib Guergachi : Au niveau des réseaux et systèmes, l’Open Source est mature et opérationnel. L’écosystème Open Source - incluant la technologie, les meilleures pratiques, les services -, est-il de son côté viable ? La question reste posée. Quand on monte dans les couches, en parlant de framework, de composants techniques réutilisables tels que les outils de persistance, de sécurité, d’authentification, on en est encore au début. Lorsqu’on atteint les progiciels, les solutions existantes relèvent plus du développement spécifique et ne bénéficient pas vraiment des communautés Open Source telles qu’on les connaît dans les domaines courants. Les offres ne sont pas du tout matures. Il n’existe pas de PGI Open Source qui puisse rivaliser avec ceux de SAP ou d’Oracle.

Cet état des lieux s’explique par le fait que l’Open Source n’est pas structurellement mature pour s’organiser autour de problématiques métier. Dans le domaine des réseaux et systèmes, le périmètre fonctionnel est clair et précis. On sait exactement ce qu’il faut faire lorsqu’on veut développer et implémenter un système d’exploitation, un moteur de bases de données ou un serveur d’applications. Les fonctionnalités sont connues et parfaitement spécifiées. Ainsi, la communauté Open Source va développer de manière sécurisée, fiable et opérationnelle une solution qui répondra à un problème précis. Par contre, dans le domaine des couches métiers, le modèle actuel de l’Open Source ne convient pas et il .

Stéphane Kimmerlin : Il y a en fait une ambiguïté sur ce qu’on appelle développement logiciel. Dans le monde de l’édition traditionnelle, c’est assez facile à définir. Dans l’Open Source, c’est plutôt un assemblage de différents composants. Bien sûr, il y a des composants matures et totalement banalisés, par exemple une pile TCP/IP. C’est un domaine connu dans lequel il n’y a pas d’innovations particulières. Il y a donc des éléments dans les logiciels libres qui sont arrivés à maturité. Mais quand on assemble ces différents éléments, obtient-on un produit comparable à un logiciel propriétaire ou commercial ? Cela dépend. Pour faire un serveur de réseau, cela ne fait aucun doute. Mais pour faire un système d’exploitation plus complet apportant des nouveautés en matière d’interface utilisateur, de logiciels d’administration, de développement d’applications, ce n’est pas sûr.

A mon sens, Open Source équivaut à mutualisation. Cela prend tout son sens quand on arrive à réunir une communauté de personnes ayant un intérêt commun. Or, c’est le cas des applications métier où une organisation aura des besoins tout à fait comparable à d’autres. Les autres domaines - dans les couches plus basses - sont devenus tellement communs et universels que ça n’intéresse plus grand monde et que ça fait partie d’un acquis. Dans le secteur public par exemple, c’est tout à fait adapté. Une mairie a les mêmes besoins qu’une autre mairie et les deux entités ne sont pas en concurrence. Ainsi, le développement d’un logiciel de gestion de crèche ou d’action sociale pourra être fortement mutualisé. Plus le marché est restreint, moins il intéressera les éditeurs traditionnels et plus le modèle Open Source sera adapté.

Prenons par exemple un SIRH destiné à ministère. Que chaque ministère lance un appel d’offres pour la réalisation d’un tel produit est plutôt contre-productif. Mais savoir si, dans les couches basses, on prend des composants Open Source ou des composants fournis par un éditeur sur le marché n’est pas vraiment stratégique.

Prenons l’exemple du RMA (Revenu Minimum d’Activité). Jusqu’ici, ce dispositif était géré par l’administration centrale. Il va désormais être pris en charge par les Régions. Dans ce cas, les Régions ont un intérêt très fort à se regrouper, à mutualiser leurs ressources et à travailler en mode Open Source. Une région pourra commencer des développements qui seront ensuite repris par d’autres. C’est là le principe originel du développement Open Source.

HG : Cette approche est intéressante, mais je pense qu’on s’éloigne des quatre caractéristiques de ce qu’est réellement l’Open Source décrit par Richard Stallman. On est plutôt dans un nouveau modèle économique de mutualisation. L’exemple de la RMA correspond au fait que l’on a défini un périmètre fonctionnel très précis. Ce qui permet de constituer une sorte de communauté. Il s’agit plutôt d’un nouveau modèle économique autorisant le partage que de l’Open Source proprement dit. La vague Open Source commence à déferler. Je dis bien commence. Qui va-t-elle emporter et où va-t-elle débarquer n’est pas encore connu avec précision.

Restreindre l’Open Source à la notion de mutualisation est un moyen de dire que cela n’existe pas vraiment. L’Open Source peut se définir comme le phénomène suivant : à chaque fois qu’une problématique est clairement définie, il s’avère qu’il devient possible grâce à la notion de licence GPL (ou assimilée) de concevoir, développer, déployer et de maîtriser l’évolution d’un logiciel.

SK : Le raisonnement tient si les conditions de la création sont réunies. Ce n’est pas parce que je mets du code en GPL que j’ai un résultat. Il faut qu’existe une communauté d’intérêt, d’où la mutualisation. L’Open Source n’est qu’une méthode possible de développement, qui, pour être utilisée et appliquée efficacement doit par définition mettre en œuvre cette convergence d’intérêt. En outre, le résultat doit être pertinent.

HG : Il faut d’un côté des spécifications clairement définies et de l’autre une cible identifiée. D’où la nécessité d’un patron de communauté, quelqu’un qui ait intérêt à ce que la communauté existe et y travaille efficacement.

SK : Une sorte de dictateur bienveillant.

HG : Toutes les communautés Open Source qui ont réussi ont mis en place une hiérarchie de développement très claire. Par exemple, le lancement de la Fondation Eclipse mise sur les fonds baptismaux par IBM. Mais ce qui caractérise l’Open Source - accès au code, modification et distribution - est fondamental. Au plan de la qualité. Mais on ne sait pas vraiment si le code Open Source est sécurisé et fiable ou bien s’il est politiquement correct de ne pas attaquer l’Open Source.

QUALITE DU CODE
Plusieurs études et analyses ont été publiées comparant la qualité des codes Open Source et propriétaires. Une, très récente, réalisée par la société américaine Coverity, indique que la qualité du code Linux est très bonne et plutôt supérieure à la moyenne. Qu’en pensez-vous ?

SK : Chez Microsoft, nous avons passé l’outil de Coverity sur une partie de notre code et il y a trouvé beaucoup moins de bugs que ceux qui ont été répertoriés. Ce genre d’outils n’a rien de révolutionnaire et existe chez les éditeurs commerciaux. Nous disposons d’outils mieux adaptés à notre production de code. Il n’y a donc pas vraiment de surprise. L’outil de Coverity a trouvé un taux de bugs de 0,17 par million de lignes de code écrites. Mais l’étude n’a pas été faite sur le code Windows spécifiquement. Les analyses que nous avons effectuées sur notre code montrent un taux de 0,12 bug par million de lignes de code, soit un chiffre tout à fait comparable. Linux est très stable, c’est indéniable, Windows aussi. Si on considère les failles de sécurité en allant sur le site de Secunia, c’est tout à fait comparable. Il n’y a pas une magie de l’Open Source qui permettrait de développer du code sans défaut.

HG : On peut établir la loi suivante : tout domaine logiciel qui peut être spécifié de manière précise sera couvert par l’Open Source. Cela est-il propice à l’innovation ? Il s’agit d’une autre question.

SK : Effectivement, tout ce qui est stabilisé est parfaitement adapté à l’Open Source. La difficulté dans le développement du logiciel est de savoir ce que souhaitent les futurs clients. Car eux-mêmes ne le savent pas très bien. Supposons qu’ils le sachent. Il y a alors plusieurs manières de parvenir au résultat. Vous voulez vous rendre d’un point A à un point B : vous pouvez prendre l’autoroute ; il y a un péage, mais vous pourrez sans doute aller plus vite tout en roulant de manière plus sûre. Vous pouvez aussi prendre une route départementale, profiter du paysage, vous arrêter dans les villages… sans payer.

HG : Dans certains domaines, il existe des autoroutes gratuites parce que les développements ont déjà été financés. On peut prendre le cas d’Eclipse financé en partie par IBM.

LOGICIELS METIER OPEN SOURCE
Dans les applications métier, prenons l’exemple des ERP. Qu’est-ce qui empêcherait de développer un "SAP Open Source" ?

HG : Techniquement, rien ne l’empêcherait, mais la question est : Qui va investir et servir de catalyseur ? Pour Linux, on sait qui a commencé pour Eclipse, c’est pareil. Ensuite, il y a une communauté qui se structure. Mais, contrairement à ce qu’on pourrait penser, le périmètre fonctionnel d’un ERP n’est pas stabilisé.

SK : Il y aussi une dimension à prendre en compte : celle de la production du logiciel. Il ne s’agit pas seulement d’avoir à disposition des centaines de développeurs prêts à travailler ensemble. Car dans l’Open Source, il n’y a pas de contrainte commerciale a priori qui force à sortir un produit dans un délai donné, de règles formelles pour cadrer les développeurs, de réelle connaissance des clients et de leur besoin. Le mécanisme de l’Open Source est par nature très orienté sur la technologie et ne cherche pas vraiment à résoudre le problème d’un client. Beauté, élégance, propreté du code sont des préoccupations dans l’Open Source qui passent souvent avant les besoins des clients.

HG : Concevoir un logiciel pour un client est à chaque fois une problématique différente. Pourquoi les ERP coûtent-ils des millions d’euros à déployer ? Parce que chaque entreprise représente un contexte très précis. On parle d’un master hospitalier, d’un master pour les banques… Les domaines fonctionnels des ERP sont très difficiles à cerner et à stabiliser. Dans le middleware – OS, service d’annuaire, Base de données – tout est parfaitement balisé.

SK : Je pense tout à fait le contraire. Le système d’exploitation que j’ai sur ma machine et celui que j’aurai dans 15 ans n’ont absolument rien à voir.

HG : Oui, si Microsoft veut continuer à exister, il faut que le système d’exploitation à cette période marque un saut quantique. Car ce que l’on appelle le noyau d’un système sera complètement banalisé. Windows n’a rien à envier à Linux, mais la réciproque est tout aussi vraie. L’avantage de Windows est beaucoup plus lié à son écosystème. En particulier, à toutes les sociétés qui ont investi beaucoup d’argent sur ce marché. L’écosystème Linux en est à ses débuts.

SK : Si cet écosystème existe, c’est grâce à la qualité du produit et sa facilité d’utilisation par rapport à d’autres. Car cet écosystème ne s’est pas construit en un jour. Dans l’environnement Linux, cet écosystème est seulement en cours de constitution. Aujourd’hui, quand on demande aux utilisateurs ce qui les empêche de passer sous Linux, les réponses sont : l’incompatibilité des applications, le manque de qualité des outils de développement, de déploiement, d’administration… L’Open Source est au milieu du gué. On peut prendre des technologies Open Source frustes mais solides, mettre des services autour et avoir un très beau résultat pour autant que les hommes soient compétents. Ou alors prendre des briques de bases sophistiquées, très stables et ajouter un peu de service pour obtenir aussi un excellent résultat. Les deux modèles sont tout à fait envisageables et peuvent très bien fonctionner.

Dans une solution, il y a toujours une partie logiciel et une partie service, car quelles que soient la qualité et l’envergure fonctionnelle du ou des logiciel(s) utilisé(s), il y a toujours une partie spécifique, liée à l’adaptation et à la personnalisation, sans parler de la prise en main par les utilisateurs. Il n’y a pas 2 PC, et a fortiori deux infrastructures informatiques, identiques dans le monde. L’objectif implicite visé par Microsoft, ou par n’importe quel éditeur traditionnel, est d’incorporer dans le logiciel le plus de fonctionnalités génériques possibles, de la prestation de service, et donc d’essayer de minimiser la partie spécifique à faible valeur ajoutée dans le système d’information. En simplifiant la réalisation des tâches de « bas niveaux », nos outils permettent aux prestataires de se concentrer sur les tâches à forte valeur ajoutée (conseil, architecture, conception, formation, accompagnement de projet, …) en limitant autant que possible les actions qui réclament l’intervention de l’être humain. Car ce qui crée la non fiabilité, c’est l’humain, tant au niveau de la conception que de l’utilisation.

HG : Si on se place à un niveau stratégique, on a la chance, avec le mouvement Open Source, de voir apparaître un concurrent potentiel qui va pouvoir causer quelques problèmes à Microsoft. Cela semblait inimaginable il y a peu. Mais, il faut un positionnement de la part des acteurs majeurs de l’industrie, en particulier derrière Linux, pour espérer que l’essai soit transformé.

___________________________________________
DEMAIN DEUXIEME PARTIE
OPEN SOURCE : SIMPLE CONCURRENCE OU NOUVEAU PARADIGME ?