Actualités

[18/05/2017] OpenShift, le nouveau livre blanc Smile

Smile publie aujourd'hui un livre blanc dédié à OpenShift, le PaaS open source orienté DevOps. A télécharger dès maintenant !

[15/05/2017] Smile décroche le label HappyAtWork 2017

Pour la 2ème année consécutive, Smile obtient le label HappyAtWork for Starters qui récompense les entreprises où il fait bon débuter sa carrière !

[28/04/2017] Smile annonce son plan strategique Open Arrow 2021 et accueille a son capital EURAZEO PME, nouvel actionnaire de reference qui succede a Keensight Capital

Smile, leader de l’intégration et l’infogérance de solutions open source, choisit son nouvel actionnaire majoritaire et s’offre de nouveaux moyens lui permettant le déploiement de son plan stratégique OPEN ARROW 2021 visant à créer un nouveau champion européen de l’IT de plus de 200M€ de chiff...

Toutes les actualités picto
       

Top consultation

Logo Smile : Open Source Solutions

Guillemet ouvrant introduction
à l'open source Guillemet fermant

Support

Support

NOUVEAU : Smile propose aujourd'hui l'offre de support la plus complète basé sur 5 points clés :

  • Guichet de support unique
  • Expertise reconnue
  • Engagement fort (SLA)
  • Satisfaction client
  • Services complémentaires

Venez découvrir notre offre de support open source : http://www.support-opensource.com

Open source et support

Le support des programmes est une question clé. Dans l’informatique en général, et plus encore dans l’open source.
 Qu’entend-on par support ? La capacité à apporter de l’aide dans l’utilisation du programme et à corriger le programme le cas échéant.

Le support peut s’adresser aux utilisateurs finaux, comme aux exploitants du programme, ou encore aux programmeurs travaillant sur le programme.

Le déploiement de programmes pour des tâches critiques, en particulier dans des entreprises, requiert absolument un support, car le risque d’une situation de blocage est trop important, cela que ce blocage soit dû à une anomalie ou à un mauvais usage, mauvaise configuration, incompatibilité, etc.

La question du support est un sujet sensible en matière de logiciel open source. En premier lieu parce qu’il y a une différence de fond, pour les produits d’origine communautaire, entre un support de communautés et un support d’éditeur. En second lieu parce que les éditeurs de produits propriétaires voudraient faire croire que le support est un point faible des logiciels open source.

Il est vrai que la licence open source porte en général en gros caractères la mention : ce logiciel est fourni en l’état, sans garanties, etc... Et de fait, il serait extraordinaire de réclamer quoi que ce soit à l’auteur qui vous a permis d’utiliser son œuvre. Mais on oublie parfois que l’absence de garantie est le plus souvent invoquée également par les licences propriétaires.

NOUVEAU : Venez découvrir notre offre de support open source ici.

Support communautaire et support d'éditeurs

En matière de support open source, il faut bien séparer deux mondes : les produits communautaires d’une part, les produits d’éditeurs commerciaux d’autre part.

Les produits communautaires (Linux, Apache, PHP, …) bénéficient avant tout d’un support communautaire. C’est à dire basé sur le volontariat de développeurs impliqués, qui répondent aux questions des utilisateurs sur les mailing-lists et forums. Et basé également sur le suivi et la prise en charge des anomalies sur les plateformes de développement communautaires.

Lorsque la communauté est active, comme c’est le cas autour des grands produits, ce support communautaire peut être d’une très grande efficacité, d’une très grande réactivité, très supérieur à un support commercial. Mais certains utilisateurs resteront chagrinés qu’il soit sans garantie, que l’on ne puisse attaquer personne si un problème n’était pas résolu. En réalité, la plupart des supports d’éditeurs commerciaux sont également sans garantie de résultat.

Outre l’aspect communautaire, se pose aussi le problème de la diversité des produits. Un système d’information peut inclure couramment plus de 10 produits différents dans la ‘pile’ logicielle : Linux, Apache, Tomcat, MySql, Hibernate... Lorsqu’un problème survient, à qui s’adressera-t-on ? Les clients professionnels demandent un interlocuteur unique, pour prendre en charge les premiers niveaux de support.

Très tôt dans le développement de l’open source, des acteurs commerciaux ont répondu à cette demande de support. C’est le positionnement des ‘distributeurs’ tels que Redhat ou Mandriva, mais aussi des premières SSLL en France, telles que Alcôve, Linagora ou OpenWide.

Du côté des éditeurs open source (MySql, eZ Publish, TinyERP), la question est différente : l’éditeur est une société commerciale et son business model est essentiellement basé sur son offre de support. Ici donc, le dispositif de support est très proche de celui des produits propriétaires. Pas identique toutefois car en parallèle, en complément au support payant de l’éditeur, il existe souvent un support communautaire, plus ou moins vivace selon les produits.

Mais le plus souvent, les corrections touchant au code ne sont assurées que par l’éditeur.

Pour les nouveaux éditeurs de l’open source commercial, le support produit est le fondement du business model, il est leur raison de vivre, leur unique source de revenus. On peut donc s’attendre à un support de grande qualité, incluant une variété d’options en termes de réactivité.

3 niveaux de support

Rappelons tout d’abord la définition usuelle des niveaux de support :

  • Niveau 1 : un opérateur non-expert prend note de la demande, la saisit dans l’outil de suivi, et consulte des instructions simples pour tenter un dépannage.
  • Niveau 2 : un intervenant expert sur une variété de domaines analyse la demande, fait un premier diagnostic du problème. Il résout le problème ou trouve un contournement dans la mesure de ses compétences, ou sinon détermine l’aiguillage approprié vers un spécialiste.
  • Niveau 3 : un intervenant expert spécialisé apporte la correction définitive.

Une correction portant sur le code source d’un programme ne peut se faire qu’au niveau 3.

Bien entendu, une règle générale en matière de support est qu’il faut limiter les intervenants aux premiers niveaux, si possible n’en avoir qu’un seul jusqu’au niveau 2, qui est en charge de l’aiguillage.

C’est ce qui est représenté sur la figure suivante :

3_niveaux_de_support

Couches logicielles

En matière de support open source, il faut bien séparer deux mondes : les produits communautaires d’une part, les produits d’éditeurs commerciaux d’autre part.

Les produits communautaires (Linux, Apache, PHP, …) bénéficient avant tout d’un support communautaire. C’est à dire basé sur le volontariat de développeurs impliqués, qui répondent aux questions des utilisateurs sur les mailing-lists et forums. Et basé également sur le suivi et la prise en charge des anomalies sur les plateformes de développement communautaires.

Lorsque la communauté est active, comme c’est le cas autour des grands produits, ce support communautaire peut être d’une très grande efficacité, d’une très grande réactivité, très supérieur à un support commercial. Mais certains utilisateurs resteront chagrinés qu’il soit sans garantie, que l’on ne puisse attaquer personne si un problème n’était pas résolu. En réalité, la plupart des supports d’éditeurs commerciaux sont également sans garantie de résultat.

Outre l’aspect communautaire, se pose aussi le problème de la diversité des produits. Un système d’information peut inclure couramment plus de 10 produits différents dans la ‘pile’ logicielle : Linux, Apache, Tomcat, MySql, Hibernate, ... Lorsqu’un problème survient, à qui s’adressera-t-on ? Les clients professionnels demandent un interlocuteur unique, pour prendre en charge les premiers niveaux de support.

Très tôt dans le développement de l’open source, des acteurs commerciaux ont répondu à cette demande de support. C’est le positionnement des ‘distributeurs’ tels que Redhat ou Mandriva, mais aussi des premières SSLL en France, telles que Alcôve, Linagora ou OpenWide.

Du côté des éditeurs open source (MySql, eZ Publish, TinyERP), la question est différente : l’éditeur est une société commerciale et son business model est essentiellement basé sur son offre de support. Ici donc, le dispositif de support est très proche de celui des produits propriétaires. Pas identique toutefois car en parallèle, en complément au support payant de l’éditeur, il existe souvent un support communautaire, plus ou moins vivace selon les produits.

Mais le plus souvent, les corrections touchant au code ne sont assurées que par l’éditeur

Pour les nouveaux éditeurs de l’open source commercial, le support produit est le fondement du business model, il est leur raison de vivre, leur unique source de revenus. On peut donc s’attendre à un support de grande qualité, incluant une variété d’options en termes de réactivité.

Dans la suite, nous distinguons 4 couches d’une plateforme open source :

  • Le système d’exploitation GNU/Linux. Le niveau 3 ne peut être assuré que par des communautés (Debian), ou des distributeurs spécialisés (Redhat, Mandriva).
  • Les composants système divers, généralement inclus dans la distribution, typiquement Apache ou Tomcat. Ceux-là également sont généralement supportés au niveau 3 par les communautés, par exemple celle de l’Apache Software Foundation.
  • Les solutions de haut-niveau d’éditeurs open source, typiquement eZ Publish, TinyERP ou bien Alfresco. Elles ne peuvent être supportées au niveau 3 que par leur éditeur.
  • Enfin, les modules applicatifs spécifiques, ou bien configurations complexes de ces applications. Ce peut être par exemple une application métier entièrement spécifique, construite sur un framework open source, ou bien des jeux de gabarits ou extensions d’un outil de gestion de contenus. Elles sont réalisées le plus souvent par un intégrateur de solutions open source, mais éventuellement par les équipes du client final. Et bien sûr, c’est celui qui les a réalisées qui est le mieux placé pour en assurer le niveau 3.

Il est clair que la stabilité va croissante entre ces 4 couches : les bugs dans Apache sont rares, mais ceux de Linux sont plus rares encore. Les solutions de haut niveau sont moins robustes que Apache, mais la probabilité de bugs est la plus forte dans les développements spécifiques, tout simplement parce qu’ils n’ont qu’un nombre limité d’utilisateurs et une moindre ancienneté.

C’est ce qui est représenté sur la figure suivante :

couches_logicielles

Ainsi, il est clair que le besoin de support est plus fort pour les couches supérieures. S’il y a interlocuteur unique, alors ce sera naturellement celui qui peut intervenir sur ces couches.

Support en l’absence d’applicatif spécifique

La figure suivante représente le cas où les produits open source sont utilisés en l’état, avec aucune ou très peu de configuration. C’est typiquement le cas d’un déploiement de la suite OpenOffice.

couches_logicielles-applicatif_specifique_1

Si la configuration inclut un produit d’éditeur en plus des produits de communautés, et toujours en l’absence de configuration spécifique élaborée, alors le client peut s’adresser directement à l’éditeur pour les niveaux 1, 2 et 3 sur son produit, et au distributeur sur les couches inférieures. Il est rare que les éditeurs souhaitent assurer du niveau 1 et 2 au delà de leur produit, sur l’ensemble de la configuration.

couches_logicielles-applicatif_specifique_2

Centre de support intégrateur

Enfin, certains prestataires proposent d’assurer un support global multi-produits en niveaux 1 et 2. C’est le cœur de métier de certaines SSLL, mais quelques SSII généralistes s’y sont mises également.

Il est rare qu’elles aient l’expertise requise pour assurer le niveau 3 sur toute la palette des composants, mais elles peuvent construire une expertise suffisante sur quelques-uns d’entre eux.

couches_logicielles-support_integrateur

Cas d’une application ou configuration spécifique

La figure suivante représente le cas où le client utilise une application spécifique, ou bien une configuration complexe d’une solution open source d’éditeur, qui a été élaborée pour lui par un intégrateur de solutions open source.

Dans ce cas de figure, l’intégrateur est le plus à même d’assurer le support de niveau 1 et 2 sur l’ensemble de la pile, en se tournant vers les expertises appropriées pour le niveau 3.

couches_logicielles-config_specifique_1

Il peut arriver toutefois que le client ait plusieurs configurations différentes, reposant sur les mêmes couches basses, et aura confié à un distributeur le support global sur ces couches.

couches_logicielles-applicatif_specifique_2

Cette seconde figure représente une alternative, dans laquelle le client final s’adresse à un distributeur pour le support du bas de la pile : système d’exploitation et composants système, et à l’intégrateur pour les composants supérieurs.