L’open-source moteur de l’open-data

Frédéric Charles est responsable de la stratégie et de la gouvernance SI au sein de la DSI de La Lyonnaise des eaux / Suez Environnement. Il anime un blog prospectif sur les stratégies de système d’information et leur contribution aux stratégies d’entreprises. Il est régulièrement consulté en tant qu’expert dans l’émission 01 Business sur BFM Business.

Nous avons souhaité rencontrer Frédéric pour qu’il nous apporte son éclairage pour open experience # 2 sur le logicel libre.

Quelle est la place du logiciel libre dans un groupe comme la Lyonnaise des Eaux ?

Le logiciel propriétaire ne tient pas ses promesses, le SaaS et l’open-source sont des alternatives.

En poussant volontairement le bouchon, on peut dire que le modèle du progiciel propriétaire n’a pas tenu ses promesses sur le long terme : le Saas et l’open-source apparaissent comme des alternatives en réponse à cet échec.

La première promesse non tenue concerne les mises à jour et la maintenance qui sont difficiles et coûteuses. La deuxième promesse est d’ordre stratégique : le modèle de survie d’un progiciel est de s’étendre progressivement vers d’autres domaines fonctionnels que celui qui a déclenché le choix initial. Cela crée des redondances fonctionnelles, une même fonction est donc payées trois fois : deux fois à l’achat des logiciels et une troisième fois pour développer les interfaces.

Les promesses initiales de réduction de coût ont été survendues. En fait, on le savait depuis longtemps (et c’est d’ailleurs pour cela que j’ai lancé mon blog) ; en effet, une grande partie des revenus des éditeurs partent en fumée dans les dépenses de marketing et de communication (salon, conventions, séminaires, réceptions…). Au bout du compte, ces dépenses sont payées par les clients.

Dans les modèles open-source, ces dépenses sont réduites, voire nulles, ce qui rend les coûts directs de ces solutions plus avantageux. On ne paye pas pour le marketing de l’éditeur mais par exemple pour des prestations de support ou du service dont on bénéficie réellement.

L’open-source a commencé à pénétrer le marché sur les couches informatiques “basses” (LAMP, Linux, Apache, MySQL, Php) et on le rencontre maintenant de plus en plus sur des applicatifs métiers. Il existe maintenant des solutions applicatives pour adresser des besoins standards, comme OpenERP, ERP5, Sugar CRM. Ces solutions sont aussi bonnes que les produits du marché car elles ont pu obtenir, avec leur modèle et du temps, une base suffisante de testeurs et d’utilisateurs pour couvrir l’ensemble des besoins fonctionnels attendus de façon standard.

Pour répondre à des besoins standard, nous achetons préférentiellement la fonction en SaaS car nous n’avons alors plus de problème de mise à jour complexes à traiter. Principalement pour des raisons de besoins encore non standards, la Lyonnaise des eaux n’a pas encore de solution métier en open-source.

En revanche lorsqu’il s’agit de répondre à un besoin générique, nous réalisons des développements sur la base de socles open-source, comme pour les développement internet (avec  liferay ou le framework Symfony2 qui a remplaçé Dupal) , la recherche (Polyspot qui repose sur Lucène et SolR), le traitement de données  (Pentaho).

Que vous apportent les solutions open-source que ne vous apportent pas les autres ?

Concernant les logiciels open-sources, nous avons dépassé les choix religieux

Les logiciels libres nous apportent une très bonne gestion des évolutions dans le domaine du web ou l’obsolescence est rapide. Ils sont aussi une très bonne base pour mettre en place un SaaS car on y gagne en flexibilité et en montée en charge.

On évoque souvent la gratuité pour justifier l’intérêt du logiciel libre. Pour nous, quand il s’agit de mettre en place un intranet mondial, nous préférons payer convenablement, cela pour être sûr d’avoir les derniers patch et un service support de qualité avec le partenaire certifié sur la solution open-source.

Vous utilisez donc de nombreuses solutions open-source, dans quelle mesure contribuez-vous en retour à ces solutions ?

Nous avons déjà eu l’occasion de partager des développements entre plusieurs sociétés, ou de les vendre. Mais cela devient vite compliqué car il faut rédiger un contrat, décrire les limites de responsabilités, etc.

Pour un opérateur comme nous, qui n’est pas un acteur du logiciel ou de l’informatique, c’est assez difficile de se positionner envers une communauté du libre comme contributeur car cela implique des responsabilités et du temps à accorder.

Si  nous entrons dans une logique d’animation de communauté un jour, il faut que nous trouvions un intérêt dans cette activité : nous le ferons donc sur des sujets proches de nos opérations, et sur des sujets proches de notre métier. La communauté serait avec nos clients ou nos partenaires.

Au-delà des logiciels, le libre s’applique à de nombreux champs, on parle aujourd’hui d’open-data, d’open-manufacturing, … Dans quelle mesure ces réflexions d’ouverture sont-elles débattues ou prises en main dans un groupe comme le vôtre ?

Nous sommes fournisseurs de services à destination des collectivités. Pour réaliser nos opérations, nous concevons et fabriquons des produits. Nous pourrions ouvrir la conceptions de ces produits. Ce n’est pas le cas aujourd’hui, mais c’est une possibilité. Car finalement, nous ne vendons pas l’outil qui nous sert à offrir le service, nous vendons l’exécution du service.

Le sujet des données a toujours été d’actualité pour nous. Quand nous assurons la gestion de l’eau d’une collectivité, nous collectons de nombreuses données de mesure de la qualité de notre service, et de la qualité de l’eau. Cette collecte est assurée dans le cadre d’une délégation de service public pour répondre à des critères réglementaires.

En revanche, ces données sont mesurées, calculées et nous les transmettons ensuite aux autorités. Seules ces dernières peuvent décider de les ouvrir ce qu’elles ne font pas aisément.

Dans ces conditions, quelles sont les opportunités de l’open-data pour la Lyonnaise des Eaux ?

Ces dernières années, dans les collectivités locales, les initiatives open-data ont été nombreuses et des progrès importants ont été réalisés, en particulier sur les licences et les formats. Ces initiatives sont rarement dans une logique de plateforme et d’API ce qui fait que, techniquement, il faudra certainement tout recommencer de zéro. On aura néanmoins appris.

De plus, les démarches d’open-data actuelles cherchent souvent à faire deux choses en même temps : la fabrique des données et la présentation des données. Ca ne me choquerait pas de couper la chaîne en deux. Quand Lapeyre et Castorama fournissent des matériaux ou des outils, ils ne se posent pas la question de savoir comment leurs clients “hackent” leurs produits en trouvant des utilisations qu’ils n’avaient pas imaginé.

Se concentrer sur la fabrication de briques réutilisables est peut être une leçon que doivent savoir tirer les entreprises.

On constate que les initiatives open-data (les Hackathons, concours d’app etc) ne concernent uniquement qu’une douzaines de grandes villes. Pourquoi ne pas faire aussi quelque chose pour les 33 000 petites collectivités de moins de 100 000 habitants qui n’ont pas les moyens d’organiser cela et qui ont des besoins simples ? Pour cela il va falloir trouver un moyen de trouver des économies d’échelles et de la personnalisation de masse.

D’une façon générale, la pression des citoyens à l’ouverture des données est une tendance forte. La RATP a été confrontée à cela quand elle a revendiqué ses droits de propriétaire sur les plans du métro. On voit bien que le fait de se retrancher derrière des contrats ne tient pas bien longtemps.

Par ailleurs, l’état se retourne parfois vers le privé pour la collecte de données publiques. C’est ce qu’à illustré l’affaire de la FNAIM… Dans ce cas, les industriels demandent légitimement que les carnets de chèque s’ouvrent.

Certains modèles économiques sont aujourd’hui bien établis : Météo France nous vend des données de météo précises, et nous les achetons parce que nous en avons besoin pour piloter. Nous achetons également des données géographique à l’IGN qui est un service publique.

Nous (Lyonnaise des Eaux) avons des données et surtout de l’expertise pour les interpréter. Dans certains cas, notamment pour les données réglementaire, tout le monde développe la même chose. De façon surprenante, les collectivités locales et les agences de l’Etat qui pourraient avoir facilement des plate-formes nationales mutualisées et mettre en commun leurs données, sont finalement encore plus éclatées que le secteur privé. Pourquoi ne pas mettre en commun ces logiciels au niveau de l’industrie ? En effet, si chacun arrive avec son progiciel séparé, on se retrouvera alors, une nouvelle fois, dans le modèle défaillant des progiciels.

C’est à creuser, mais l’idée de mettre à disposition des données réglementaires et de développer le “lecteur” en open-source, en commun avec d’autres acteurs, publics ou privés, est une option qui va peut-être se dégager avec le temps.

La DSI devra alors savoir adopter une posture différente et travailler en commun avec les DSI des autres parties prenantes.