Logiciels Web d’entreprise : pour en finir avec le dogme du « libre »

par
   

Buzzwords entourant les logiciels webQuand vient le temps de choisir une solution technologique d'entreprise, un type de question revient très souvent : quel type de solution est le plus souhaitable?

Au-delà de la vocation du système lui-même, la question prend des formes très variées, si bien qu'on peut rapidement se perdre dans des débats dogmatiques et des comparaisons frivoles où les demi-vérités trébuchent dans les buzzwords.

Pourtant, dans plusieurs cas, les solutions opposées par certains ne sont pas mutuellement exclusives. Tous ces termes à la mode ne répondent pas nécessairement aux mêmes préoccupations, et il est essentiel d'explorer les mythes et réalités entourant ces questions avant de choisir un système et un fournisseur.

Cette réflexion est d'autant plus essentielle lorsqu'il y a un client moins habitué aux questions technologiques dans la pièce, qui devra prendre les bonnes décisions sans être noyé de termes techniques.

À mon avis, pour sortir des dogmes et y voir plus clair, il est essentiel d'isoler trois variables :

  1. l'accès au code
  2. le modèle de distribution
  3. l'approche contractuelle (facturation/licence).
Voyons comment être bien équipé pour naviguer autour de ces trois axes.  

1. L'accès au code

Le code source ouvert dans les solutions Web : souhaitable, mais vraiment essentiel pour tous?

À priori, cette variable est simple à interpréter : ai-je accès au code ayant servi à bâtir l'application (pour l'auditer ou le modifier)?

La réalité est nettement plus complexe. Personne ne vous dira que sa solution est « fermée ». Des APIs, des modules, des interfaces ou fichiers de configuration ou la possibilité de créer des extensions permettent d'ajuster presque toutes les solutions d'entreprise actuelles, y compris des solutions propriétaires et commerciales.

Logiciels ouverts ou fermés

Un développeur aimera souvent la liberté quasi-totale d'une solution ouverte, et il est d'ailleurs là pour vendre du développement. Toutefois, une solution qui limite les possibilités permet parfois aussi de se recentrer sur l'essentiel en adoptant des pratiques typiques et simplifiées avec un minimum d'exceptions (tout en évitant que des mains moins informées touchent des parties sensibles du code source). D'ailleurs, plusieurs recommandent de ne jamais toucher le code source au coeur d'une application (même lorsqu'il est accessible), au risque de compliquer les mises à jour futures.

De même, même si une solution est développée à code source ouvert, avec un langage très répandu, il n'y a aucune garantie qu'un autre développeur comprendra rapidement comment elle est construite et comment la faire évoluer à coût raisonnable.  L'utilisation de cadriciels (frameworks) communs aide cependant beaucoup.

Des questions pour se préparer

Au final, on devrait surtout se demander :

  • Cette solution est-elle faite pour ce que je veux faire?
  • Quel degré d'ajustement sera nécessaire, et quel budget y investira-t-on?
  • Quelles seront les conséquences des ajustements et extensions sur les mises à jour futures?
  • Combien de composantes sont à réévaluer à chaque mise à jour? Quelle est la fiabilité de mon portfolio de composantes, modules et extensions? Qu'arrivera-t-il si un module-clé devient inutilisable après la mise à jour du coeur de mon application? Comment mitiger ces risques?
  • Veut-on que les ajustements soient faits par des développeurs ou directement par nos utilisateurs d'affaires (ex.: gestionnaire marketing)?
  • A-t-on la compétence pour effectuer ces ajustements, veut-on développer cette compétence à l'interne (dans un langage particulier)?
  • Si ce n'est pas le cas, qui peut-on mandater pour effectuer ces ajustements? La compétence est-elle abordable avec ces technologies et dans ces langages?
  • Sera-t-on captif d'un nombre limité de firmes ou de développeurs compétents (dans notre région, si applicable)?

Attention aux dogmes/mythes :

  • Ce n'est pas parce que le code est accessible qu'il est nécessairement souhaitable de le modifier.
  • Ce n'est pas parce que le code est accessible aux développeurs qu'il est moins sécuritaire.
  • Ce n'est pas parce que le code est accessible que vous trouverez des ressources compétentes pour l'éditer à prix avantageux.
  • Ce n'est pas parce que le code est inaccessible qu'il est impossible de configurer ou personnaliser la solution (par exemple via des interfaces de gestion).
  • Ce n'est pas parce que le code est accessible que le coût total sera inférieur.
  • Ce n'est pas parce qu'un site est basé sur « des technologies ouvertes » qu'il sera nécessairement facile de changer de fournisseur ».

2. Le modèle de distribution

Hébergement, opération et gestion de solutions Web : pour quel niveau de service paiera-t-on?

Ici, les propositions des fournisseurs n'ont pas fini de se multiplier. Certaines solutions sont fournies sans garanties, et d'autres sont vendues comme un service clé en main, accessible par un utilisateur non-technique dans la minute suivant son achat.

Au final, on a ici affaire à un continuum opposant le logiciel en téléchargement à un extrême (solutions « tablette »/packaged software : à l'entreprise cliente d'en faire ce qu'elle peut) et du véritable software-as-a-service (SaaS) à l'autre (l'entreprise se procure alors davantage un abonnement récurrent à un service hébergé et géré qui inclut l'usage d'un logiciel donné). Entre ces deux extrêmes se trouvent des solutions hébergées ou gérées, où l'entreprise et ses fournisseurs se partagent les responsabilités pour opérer le logiciel. Selon le type d'hébergement, certains parleront de « solution cloud », un terme qui réfère à une façon d'héberger, mais peut supporter différents modèles de distribution.

Implantation des logiciels Web d'entreprise : Rôles et responsabilités

Parfois, la même solution peut être donnée par un fournisseur et revendue par un autre, avec un support amélioré. Par exemple, il est possible de télécharger la version communautaire de Magento, mais certaines firmes vendent un service de configuration, hébergement et gestion clé en main de sites de vente en ligne basés sur cette solution.

Il existe aussi une foule d'autres façons de partager les responsabilités de configuration, de support et d'opération.

Des questions pour se préparer

On devrait ici se poser quelques questions et utiliser les points suivants dans la négociation :

  • Est-il préférable de gérer soi-même la solution ou de confier une partie de son opération à un tiers, qu'il s'agisse du créateur de la solution, d'un de ses distributeurs/revendeurs, ou d'un tiers? Nos équipes sont-elles prêtes?
  • Est-on prêt à confier l'entretien et l'évolution de la solution à une firme externe pour toute sa durée de vie? Comment devrait-on distinguer clairement les responsabilités des différentes équipes?
  • Veut-on un engagement distinct avec les différents fournisseurs (ex.: acheter la licence à l'un, la faire implémenter par l'autre)?
  • Quelles sont les inclusions proposées par le fournisseur, surtout en ce qui a trait au plan de support, de gestion et d'hébergement?
  • Quels sont les risques encourus si un des intermédiaires impliqués cessait de pouvoir offrir du support (ex. : faillite, changement de technologie)?
  • Quel type de support humain est nécessité par une solution clé en main (ex. : basée sur un SaaS) : technique, contenu, configuration?
  • De quel type de documentation et de formation notre personnel aura-t-il besoin?

Attention ici aussi aux à prioris

  • Ce n'est pas parce qu'une solution est hébergée qu'elle est gérée.
  • Ce n'est pas parce qu'un développeur implante votre solution qu'il formera vos équipes pour l'utiliser.
  • Ce n'est pas parce qu'un développeur recommande un hébergeur qu'il garantit la performance de votre solution une fois implantée.
  • Ce n'est pas parce qu'il est possible d'avoir de l'hébergement à bas prix (ou à l'interne) que cette approche est la plus rentable (en commerce électronique, quelques secondes de temps de chargement peuvent faire perdre beaucoup de revenus).
  • Ce n'est pas parce qu'on a une solution à une « grande communauté en santé » qu'il sera facile de trouver une réponse à ses questions.
  • Ce n'est pas nécessairement la firme qui a développé un logiciel qui offre le meilleur support pour l'opérer (parfois un partenaire local comprendra mieux les enjeu de l'entreprise cliente).
  • Ce n'est pas parce qu'un fournisseur vous propose à la fois l'hébergement, le support et l'entretien que vous devriez lui confier tous ces rôles (attention toutefois à ne pas devenir la courroie de relais entre plusieurs intervenants qui se renvoient la balle en cas de problème).

3. L'approche contractuelle

Licences et facturation de solutions Web : que possèdera-t-on?

Ici, on pense immédiatement aux solutions gratuites et aux solutions payantes. En allant un peu plus loin, on peut diviser ces dernières en plusieurs catégories :

  • les solutions commerciales (distribuées telles quelles ou configurées par plusieurs intégrateurs/revendeurs)
  • les solutions propriétaires (un fournisseur vend sa propre solution, sans revendeurs)
  • les solutions sur mesure

Les solutions commerciales, mêmes payantes, jouissent maintenant souvent de plusieurs des avantages parfois associés aux solutions open source sur cet aspect. Étant réutilisées de façon très similaire pour de nombreuses entreprises, elles sont habituellement accompagnées de beaucoup plus de documentation, s'appuient parfois sur une communauté d'utilisateurs très active (ou même une place de marché d'extensions) et donnent une mobilité advenant la volonté de changer de fournisseur d'implémentation. Si les sites Web de leurs créateurs sont parfois avares de détails (nous sommes les premiers à en rechercher), on gagne beaucoup à les contacter pour demander une démonstration, une estimation ou plus de documentation.

Une solution propriétaire du fournisseur a peut-être quelques avantages uniques (à clarifier), mais limitera la mobilité de l'entreprise cliente qui voudrait changer de fournisseur.

Finalement, un fournisseur facturera typiquement davantage pour du sur-mesure que pour une solution qu'il revend à de nombreux clients (il reste de rares aspects de chaque projet où un peu de sur-mesure reste nécessaire). Encore ici, il existe de nombreux compromis possibles, surtout si le fournisseur propose de revendre une technologie initialement développée sur mesure pour un client (l'exclusivité a un prix). 

Le modèle de facturation va plus loin. Typiquement, on paiera un prix initial plus élevé (souvent forfaitaire) pour du sur-mesure réutilisable par l'entreprise à sa guise, alors qu'il est courant de facturer une solution commerciale avec une licence à l'utilisation, que ce soit au nombre de serveurs (ou cœurs de processeurs) utilisés, ou même aux ventes obtenues. Dans tous les cas, il existe de plus en plus de contrats au partage de revenus, où le risque (et le contrôle) se partagent entre l'entreprise et son fournisseur. Dans cette situation, un fournisseur recherchera cependant plus de contrôle sur les activités en ligne de l'entreprise cliente... pour garantir son propre succès. 

Dans chaque cas, les garanties, le service et le support peuvent aussi grandement faire fluctuer la portée de l'entente.

Sur cet aspect, la meilleure arme de l'entreprise cliente est probablement de réunir ses experts financiers, techniques et légaux pour peser le pour et le contre de chaque possibilité (c'est aussi une excellente façon de briser les silos à l'interne), puis de trouver un terrain d'entente avec ses fournisseurs en fonction d'objectifs d'affaires préétablis.

Des questions pour se préparer

Ici, les principales questions et points de négociation pourraient être les suivants :

  • Quelle solution offre le meilleur rendement (retour sur investissement) en fonction des objectifs et cibles de l'entreprise, en considérant tous les coûts et revenus d'opération prévus?
  • Qui détient la propriété intellectuelle de quelle partie de la solution? Protège-t-on les éléments uniques stratégiques de notre solution?
  • Quelles sont les implications des licences de chaque composante de la solution obtenue (ex. : partage du code, paiement d'une redevance annuelle)?
  • Pour quoi paie-t-on : un produit, une location, des honoraires de développement, ou un pourcentage de nos revenus futurs?
  • Comment cela influence-t-il nos scénarios prévisionnels (ex. : pessimistes, réalistes, optimistes)?
  • Quelles dépenses pourraient être considérées comme un investissement? Lesquelles sont des dépenses d'opération?
  • Quel impact la structure de notre projet Web a-t-elle sur notre fiscalité ou nos résultats annuels sur 4-7 ans?
  • Quel type de risques prend-on et comment les partage-t-on avec nos fournisseurs?

De nombreuses précautions sont toujours de rigueur

  • Ce n'est pas parce qu'une solution est gratuite que sa licence est plus permissive : des licences comme Creative Commons et GNU peuvent notamment régir l'utilisation commerciale, la redistribution, la modification, etc., parfois même avec plus de contraintes que des solutions commerciales.
  • Ce n'est pas parce qu'une entreprise paie pour un droit d'utiliser un logiciel qu'elle en est le propriétaire ou peut le réutiliser à sa guise (vérifier la portée exacte de chaque licence achetée : nombre de sites, domaines, serveurs, cœurs, etc.).
  • Ce n'est pas parce qu'une solution est gratuite que son TCO (total cost of ownership) est avantageux.
  • Ce n'est pas parce qu'une solution est à code fermé qu'elle n'est pas gratuite (pensez à Google Analytics!).
  • Ce n'est pas parce qu'une solution est à code ouvert qu'elle est nécessairement gratuite.
  • Ce n'est pas parce qu'une solution est propriétaire que son code est 100 % inaccessible (même si cela est fréquent, et c'est toujours un point à discuter/négocier avec vos développeurs).
  • Ce n'est pas parce qu'une solution est payante que son code source est inaccessible ... D'ailleurs, si on vous facture pour du sur-mesure, il serait logique de demander l'accès au code!

Des hybrides inévitables

Les sites d'entreprises d'aujourd'hui s'opèrent habituellement avec un heureux mélange de solutions ouvertes, fermées, téléchargeables, hébergées, gérées, SaaS, gratuites, payantes, à l'utilisation, sur-mesure, etc.

Par exemple, entre le gestionnaire d'un site et le client final, il pourrait y avoir (et je suis certain d'oublier beaucoup de couches juste pour simplifier!) :

  1. CPanel
  2. Linux
  3. mySQL
  4. Apache
  5. PHP
  6. WordPress
  7. Disqus
  8. Safari In-app browser
  9. Application Facebook
  10. iOS

En quelques secondes, un constat est évident : il sera impossible de tout contrôler ou de tout aligner sur un principe général d'approvisionnement (désolé!). Dans un contexte d'affaires, il est préférable d'effectuer la sélection de fournisseur Web avec neutralité en fonction de sa valeur d'affaires (ex. : TCO, rendement, alignement stratégique) que celle qui respecte un principe dogmatique.

 M'abonner au Point de Repère

Chaque mois, soyez au fait des trouvailles, des bonnes pratiques et de nos nouvelles avec l’infolettre d’Adviso. À tout moment, il vous sera possible de vous désabonner. Politique de confidentialité.

Si vous préférez, écrivez-nous à

conseil@adviso.ca

Ou téléphonez-nous directement au

514 598 1881

Merci de votre demande!

Vous recevrez une réponse de notre part sous peu.

×

Une erreur est survenue

S’il vous plaît nous contacter directement par courriel à l’adresse conseil@adviso.ca ou par téléphone au 514-598-1881. Merci !

×

 

COMMENTAIRES

  1. Etienne Delagrave

    Belle analyse Simon.

    Tu as raisons de mettre en doute ce préjugé presque universel qu’une solution à code ouvert est nécessairement supérieure.

    Les nouvelles solutions les plus prometteuses sont de plus en plus cloud et donc à code fermé mais permette d’accomplir beaucoup en peu de temps. Je pense par exemple à Contentful, une solution venu de d’Allemagne qui ne semble pas avoir traversé la frontière.

    Aussi, je crois qu’on a peut-être un peu trop peur d’essayer de nouvelle solution. On dirait que dès qu’il ne s’agit pas de Drupal, WordPress ou Magento, le entreprise ont peur de se lancer, de peur qu’il n’y ait pas de fournisseur alternatif. Une peur légitime mais dangereusement conservatrice.

    Répondre

Laisser un commentaire

XHTML: Balises autorisées <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>