J’entends souvent dire qu’un contrat de support couvrant l’ensemble des logiciels libres sert uniquement à rassurer sa hiérarchie (« en cas de problème, on a un recours »), mais qu’en pratique, lorsqu’on rencontre une difficulté, soit on se débrouille par soi-même, soit on passe un contrat ad hoc avec une entreprise experte du sujet.
Avez-vous des exemples pour illustrer ou infirmer ces propos ?
C’est le principe d’une assurance : on en prend une pour se rassurer mais en pratique, quand il faut l’utiliser, on a parfois des surprises… Enfin , ça permet tout de même d’avancer !
Ce n’est pas vraiment différent d’un support sur certains logiciels propriétaires : les très gros éditeurs corrigent rarement leurs produits pour un client. Les correctifs arrivent parfois uniquement dans les versions supérieures.
Dans les faits, dans un support généraliste, les entreprises qui assurent le support ne disposent pas de toutes les compétences sur toutes les souches. Certains produits sont très complexes. d’autres sont complexes et critiques, mais heureusement la communauté reste très réactive. Ex PostgreSQL.
Il est de toute façon impossible matériellement de faire un appel d’offre ou un contrat spécifique avec 300 entreprises spécialisées et il est nécessaire qu’un intermédiaire assure une gouvernance pour répondre aux besoins de l’administration.
Peut-être que certains composants critiques ou spécifiques peuvent sortir d’un contexte plus généraliste et faire l’objet d’un accord particulier avec l’Administration : PostgreSQL, LibreOffice, Ubuntu, messagerie… ?
En ce qui concerne mon ministère, le marché est utilisé comme une assurance et permet l’adoption plus facilement de solutions libres.
Malheureusement, ce marché favorise plutôt les grandes SSII généralistes que les petites sociétés spécialisées et ayant une expertise pointue sur une souche en particulier …
Nous travaillons depuis des années sans marché de support, ce qui nous permet de solliciter à l’occasion des experts que l’on peut choisir Hors marché. Bien sur cela suppose des prestations limitées en volume mais on se rattrape sur la qualité 
Effectivement, au regard des consommations actuelles du support interministériel, on pourrait penser que des contrats spécifiques sur OBM, Maarch et LibreOffice couvriraient les 3/4 des besoins de support et que le reste pourrait peut-être se faire sous forme de mise en concurrence simplifiée, comme le suggère @luc.
Le principe d’une assurance, certes, mais auriez-vous l’idée de passer un marché de support « logiciels propriétaires » et de lister dans tous les domaines, aussi bien système que poste client, base de données, que sécurité etc. tous les outils possibles… Évidemment non. Qui pourrait croire à une telle assurance ? Personne.
C’est pourtant ce qui a été fait avec les logiciels libres. C’est une situation très frustrante pour les petites SSLL spécialisées, qui ont contribué à l’émergence du marché du libre et qui se retrouvent de facto sur la touche face à de tels marchés impossibles.
Je suis Jean-Paul Argudo, gérant élu de la SARL SCOP Dalibo, société d’expertise PostgreSQL (élue au niveau « Premium » par la communauté elle-même aux côtés d’autres sociétés internationales, voir http://www.postgresql.org/about/sponsors/ , tout en haut de la liste).
Je n’ai que trop d’exemples à citer qui illustrent votre propos: le contrat interministériel des logiciels libres par exemple, est toujours vécu par mes interlocuteurs comme une contrainte. Simplement, quelle que soit la société qui ait ce marché, elle ne peut être que généraliste de l’Open Source. Dans le meilleur des cas, elle sera aussi spécialisée sur quelques briques Open Source.
Hors, en ce qui concerne PostgreSQL et les projets qui y sont associées (par exemple PostGIS, pgAdmin, phpPgAdmin, PoWA, OPM, pgBadger et j’en passe), mes interlocuteurs ont besoin d’expertise. Ils sont donc obligés de trouver des moyens pour travailler avec nous via des contrats « ad hoc » comme vous dites.
J’apporte ici d’un bloc des réponses à plusieurs questions et commentaires que j’ai lu sur ce thread. C’est assez long, mais ça devait être fait:
1/ «Je n’ai pas besoin de support, je fais appel à un expert de temps en temps«
Notre expérience nous montre que nos audits suscitent beaucoup de questions et d’évolutions à posteriori. Notre but est d’assister les utilisateurs sur le long terme.
Nous avons constaté qu’un audit ponctuel de quelques jours peut certes amener des améliorations mais si ces avancées ne sont pas suivies dans le temps, leur impact tend à s’estomper lorsque l’utilisation évolue ou, simplement, lorsque le temps passe.
Sur le long terme c’est mauvais calcul et nous n’encourageons pas nos clients à aller dans cette direction: c’est PLUS CHER et MOINS EFFICACE qu’un support!
(Quasi …) Tout le monde a un contrat de maintenance pour la photocopieuse ou la machine à café de l’entreprise.
Et vous n’en auriez pas pour vos données? Sont-elles réellement moins importantes?
Enfin, un argument essentiel, c’est que le Support est notre seul récurrent! Sans celui-ci nous ne pouvons pas assurer des embauches sereinement, et surtout, contribuer à la communauté via une R&D efficace. Signer un support chez nous ou dans d’autres sociétés qui jouent le jeu de l’Open Source (autrement dit, des « pure players »), c’est vous permettre d’avoir les meilleurs experts à tout moment et de pérenniser nos entreprises. D’autant qu’il s’agit de la plupart d’entreprises de droit français et non délocalisables.
2/ Ça ferait trop de marchés à gérer!
On m’a déjà servi cet argument lors de ma visite à la Disic en 2014, plusieurs fois. Pierre-Yves là très bien dit: vous ne feriez pas de marché « pour l’ensemble des logiciels propriétaires »… Alors pourquoi le faire pour les logiciels libres? Sont-ils moins importants à vos yeux? Ce que je vois, c’est que PARTOUT dans l’administration Française, le message de la circulaire Ayrault de 2012 a été pris au pied de la lettre: ça migre de partout à PostgreSQL. Et nous ne pouvons aider que de manière sporadique les utilisateurs à y aller, car il nous est impossible d’avoir un support digne de ce nom ?!
Quel est exactement le soucis à avoir « trop de marchés à gérer »? Si on remplace à terme le marché Oracle par le marché PostgreSQL, le marché Microsoft par le marché Linux, etc… À mon humble avis c’est pareil.
Notez enfin, qu’il est beaucoup plus facile de trouver des gens compétents pour gérer des achats que des experts en logiciels libres. Dit autrement, je trouve qu’il serait dommage de limiter l’ouverture de l’état aux entreprises du logiciel libre en prétextant que cela va charger la cellule achats du gouvernement! Comprenez bien que les économies réalisées en utilisant le Logiciel Libre devraient très rapidement combler l’investissement dans les cellules achats du Gouvernement 
3/ Se grouper !
Reste que j’entends la demande d’un « Guichet Unique »… Nous avons fait une alliance de circonstance avec 2 autres sociétés du libre pour répondre à un appel d’offre d’un géant de l’énergie française. Nous attendons les résultats… Et nous avons de réelles chances de l’emporter. À ma connaissance, ça serait une première, nos 3 sociétés rassemblant un peu moins d’une 100aine de personnes, avec une expertise combinée très pointue dans plusieurs domaines, en particulier de l’infrastructure (OS, sécurité, serveurs, PostgreSQL… etc) mais aussi de la partie applicative (monde Java).
Alors voilà, si nous arrivons à transformer cet « essai » très pragmatique, nous construirons ensuite ce qui pourrait être le nouvel interlocuteur de l’état: une structure unique, sorte de « chapeau », dont les contours seraient à définir. Cette structure permettrait alors à tous les services de l’État d’avoir accès à la meilleure expertise, et en français.
Nous avons joué le jeu pendant de trop nombreuses années « avec les SSII » qui ont simplement margé sur notre dos, sans jamais nous donner une seule miette de récurrent annuel. C’est aujourd’hui terminé. Ceux là se sont enrichis grâce à nous, et à nos dépends à tous : nous parlons d’argent public.
J’arrête là, j’aurais de quoi écrire un livre sur le sujet.
Bien à vous,
Le support est-il réellement utilisé en tant que tel ? Pas juste pour se couvrir ? Sur LibreOffice, le nombre de tickets comparé à une estimation de l’utilisation du logiciel montre tout de même un support soit très peu utilisé, soit les utilisateurs ne savent pas qu’il existe. Surtout que bon nombre de tickets sont tout simplement des questions sur les correctifs de sécurité ou de nouveaux bugs créés par le support lui même.
Bonsoir Arnaud.
Les correctifs de sécurité, que ce soient des correctifs originaux ou des backports, restent une activité essentielle
dans le marché de support et ce ne sont pas les utilisateurs qui sollicitent ces correctifs mais les RSSI par le biais du CERTA et rien que pour ce sujet, on a besoin du support. Ces correctifs sont généralement bien traités et même assez rapidement par le support.
Maintenant, je reconnais que je vais avoir plus de mal à vérifier la pertinence et la qualité de ce type de correctif contrairement à un bug utilisateur.
Concernant les bugs déclarés par les utilisateurs, ils sont effectivement peu nombreux. Je ne sais pas forcément quoi en penser : Je suis en relation avec de nombreux correspondants locaux qui connaissent bien le support mais , à part un bug qui touche tout leur service (généralement un modèle de Document mal formé , une configuration serveur particulière …) il n’y a pas de mauvaise surprise et peu de remontées individuelles. (c’est peut être que le produit fonctionne bien ou qu’il est peu utilisé ou que les utilisateurs n’ont pas envie de déclarer un problème …
Les effets de bord d’un correctif existent parfois mais touchent rarement le service pour lequel on corrige le problème : dans ce cas, ie service concerné par l’effet de bord continuer à utiliser l’ancienne version et tout se passe bien 
Cordialement
Christophe
Outre ce à quoi sert un contrat de support habituellement.
ce contrat devrait être utile pour le logiciel libre s’il comporte une clause obligeant les prestataires à redéposer le code qu’ils produisent à l’occasion de ce marché de support.
Car le code produit beaucoup de service… mais le service produit bien peu de code!
Tout à fait d’accord ;
le modèle de « support de LL » est la porte ouverte à rester dans un pur modèle de consommation/utilisation de logiciel libre, surtout pas de valoriser le modèle de contribution , qui est celui par lequel la communauté existe et subsiste. C’est aussi un pur modèle de désintermédiation du consommateur du logiciel libre avec la communauté et son innovation, et c’est un modèle dans lequel le client s’enferme dans ce que le prestataire lui fournira comme décision de gestion des update/correctifs/évolutions ; la porte ouverte à des « forks » ; sans parler de la pérennité dans le temps, et des coûts associés.
Un contrat de support devrait être accompagné, si ce n’est de clauses de contribution, du moins de tout un ensemble de services couvrant la maintenance (fourniture des patches, évolutions, versions mineures ou majeures si celles-là existent, …) et des garanties de pérennité dans le temps d’un environnement déployé ou garantie de supportabilité (au même coût) dans le temps.
Dernier point, le niveau de « support » apporté dépendra évidemment de la complexité de la solution opensource considérée ; plus la solution est simple (par ex apache) , plus simple et logique est la mise en oeuvre et donc la vente et l’utilisation de prestation de pur service de support LL ; plus la solution est compliquée (dans son assemblage - distro Linux- ou son cas d’usage - Openstack- , plus complexe est la mise en oeuvre de support uniquement et plus il faut s’en éloigner, en tant que client.
@ Arnaud , tout à fait …
si le code/logiciel est bon, ET qu’il est bien industrialisé dans le temps (chaîne de délivrance des updates/patches, versions), alors le support est très très très peu utilisé.
Cela pose la question de quelle valeur donner réellement à du pur support, et/ou quels autres services attendre d’un prestataire de service autour lu logiciel libre (autre que du support). Et donc de définir ce qu’est le « support »…
Je l’ai déjà écrit ailleurs, mais je le répète ici. D’un côté, on a des SSII (sociétés de service en ingénierie et informatique), davantage spécialisées en logiciels propriétaires (même s’il peuvent proposer quelques supports en matière de logiciels libres), et, d’un autre, des SSLL (sociétés de service en logiciels libres), dont le cœur de métier est le logiciel libre (je ne pense pas -mais je peux me tromper- qu’ils proposent grand chose en matière de logiciels propriétaires ^ ^).
Bonjour,
Les discussions sont très orientées autour des logiciels « non métiers » mais comment percevez-vous le support des logiciels libres métiers ? Pour notre compte (je suis gérant de la SSLL atReal) nous assurons la maintenance de logiciels libres métiers avec des engagements de suivi réglementaire, d’assistance aux utilisateurs et contribution au tronc commun des correctifs développés dans le cadre de cette maintenance. Chaque contrat de maintenance contribue à nous donner les moyens de contribuer au développement des logiciels libres concernés sans financement direct.
Dans le cas d’un contrat de support généraliste sur les logiciels libres, est-ce que ce type de logiciel est inclus automatiquement ? Si c’est le cas comment peut être gérée la maintenance et le suivi réglementaire ? Et comment arriver à forcer la contribution ? (ce sera toujours trop cher ou trop compliqué…)
Bonjour,
Sans préjuger de ce que sera le prochain CCTP, un logiciel libre entre dans le marché de support quand
Mais il est certain qu’un guichet unique pour traiter les questions, problèmes et les bugs reste une cible pour l’Administration sans compter l’avantage d’un support juridique existant.
Cordialement,
Christophe
Dans le cas des projets ayant une licence de type colyleft; c’est déjà le cas vu que les utilisateurs peuvent demander à l’état l’accès aux sources sous licences, mais pas sur les produits sous licences sans copyleft. Par contre d’obliger la redéposition du source peut être compliqué à appliquer, est-ce suffisant de déposer un .patch sur une mailing list alors que le projet utilise Gerrit, ou de proposer pour une branche qui est incompatible avec le mode de fonctionnement du projet ?
Merci de ta réponse Christophe,
Le support devrait tout de même être plus actif et proposer les mise à jour de sécurité au plus tôt, sans avoir besoin d’attendre de la sortie d’une version avec la correction dans les release notes ou la fin du discolsure du CVE pour se demander s’il est pertinent de créer une version avec le correctif ou non.
Dans le cadre d’un projet interministériel opensource, j’ai à deux reprises fait appel au support logiciels libres sur la technologie Postgresql. Cela a permis de mobiliser très rapidement quelques experts pour évaluer les difficultés de performance et identifier quelques solutions rapides à mettre en place. Il faut en revanche veiller à être sur une version supportée, ce qui nécessite de faire un peu de veille et/ou du lobbying auprès du COPIL pour les versions supportées. Pour ma part, c’est donc un bon moyen d’expertise.
Bonjour Arnaud,
Dans l’absolu, l’État devrait avoir ce type de support sur la totalité des codes utilisés dans l’Administration, mais dans le cadre de nos marchés de support niveau 3, le prestataire n’est pas chargé contractuellement de l’audit de sécurité des codes qui lui sont soumis pour le support (La tâche serait « pharaonique » et hors des moyens qui nous sont alloués)
Quand un bug de sécurité est détecté, (par la communauté ou par un organisme indépendant), le temps que nous ayons l’info, que le bug soit déclaré au prestataire, en fonction de l’importance de la faille) , le bug a 99 % d’être déjà rapidement corrigé dans les versions les plus récentes et le prestataire est juste chargé du backport. Je n’ai jamais eu le cas d’avoir connaissance d’un bug connu et pas corrigé au moment de notre demande.
Christophe
Je suis exactement dans la même situation avec Pentaho. Et le bilan est finalement décevant : je trouve plus facilement une réponse en consultant/interrogeant les différents forums disponibles sur le net, voire même en passant par Stackoverflow.
Pouvoir confier le support à une société ayant une réelle expertise sur le produit permettrait non seulement une meilleure réactivité, mais également un reversement certain de ses contributions à la communauté.