Dans la mesure du possible, Made privilégie les plateformes open source et les standards ouverts pour le développement et la mise en ligne.
Ce n’est pas à dire que les technologies propriétaires n’ont pas leur place. Parfois, une vision singulière d’un produit se dilue dans la collaboration — Apple en est sans doute l’exemple historique le plus parlant. Les logiciels destinés à des marchés commerciaux bien délimités, comme la billetterie, peuvent effectivement être mieux servis par du propriétaire. Mais pour ce qui est de la plomberie d’Internet, nous pensons que l’open source a tranché le débat il y a belle lurette.
Avec des stacks open source, le seuil d’entrée pour « tâter le terrain » est très bas
Vu sous l’angle budgétaire, la différence la plus évidente, c’est l’étiquette de prix. Il faut parfois creuser pas mal pour trouver le tarif d’une solution propriétaire — et quand on le trouve, il est souvent à couper le souffle comparé au $0 de l’équivalent open source. Mais se focaliser uniquement sur ce chiffre serait naïf. L’open source n’est pas toujours plus accessible, et le coût total de possession — installation, maintenance comprises — mérite d’être pris en compte.
Le vrai avantage de l’open source, c’est de pouvoir participer à la conversation. Peut-être qu’il s’agit de faire remonter une fonctionnalité indispensable dans un backlog produit. Ou peut-être de se retrouver à déboguer en urgence sur Slack à 3h du matin pour limiter la perte de paquets quelque part sur un réseau. Les DSI préféreront toujours la tranquillité d’un contrat de support entreprise — mais c’est de l’assurance, rien de plus. Nous trouvons les communautés open source bien plus réactives et créatives. Celles qui se portent bien veulent améliorer Internet pour tout le monde — utilisateurs comme développeurs.
Avec des stacks open source, le seuil d’entrée pour « tâter le terrain » est très bas. Pas besoin de communiquer ses coordonnées bancaires, pas d’analyse coût-bénéfice à mener, pas même de formulaire de contact à remplir pour démarrer. GitHub est le point d’entrée naturel. Cela encourage les développeurs à explorer leurs options face aux problèmes du moment. Enfermé dans un stack propriétaire, on attend du vendeur qu’il règle tous les problèmes — et quand on n’a qu’un marteau, tout ressemble à un clou. On se coupe des patterns de développement et d’architecture utilisés par la communauté au sens large. Une sorte de syndrome de Stockholm centré sur le vendeur s’installe.
Les enjeux de montée en charge sont au cœur des projets open source qui font tourner l’infrastructure d’Internet
Autre avantage clé de l’open source — et celui-là touche directement aux préoccupations de nos clients —, c’est sa capacité à monter en charge. Normal : les enjeux de scalabilité sont au cœur des projets open source qui font tourner l’infrastructure d’Internet. IIS est un bon serveur web, .Net est un bon framework, mais la cible de Microsoft, ce sont les DSI en entreprise. Ses réglages par défaut sont pensés pour les intranets — des niveaux de trafic stables et modérés. Nos clients, eux, connaissent un trafic habituel ponctué de pics extrêmes, sans période de chauffe. On ne trouve pas énormément de documentation accessible sur la montée en charge du stack Microsoft avec une simple recherche Google, parce que ce n’est pas le problème que rencontrent la plupart de ces développeurs. Le stack peut scaler — ce n’est juste pas dans la culture.
Il est possible de faire tourner des systèmes d’exploitation propriétaires sur Amazon Web Services, mais ça va à contre-courant : la lingua franca des technologies cloud, ce sont les stacks open source. Adopter les patterns d’AWS est bien plus naturel si vous utilisez une variante du fidèle stack LAMP.
Sous sa nouvelle direction, Microsoft est devenu nettement plus ouvert aux développeurs et a progressivement adopté certaines pratiques de l’open source. Dans le même temps, l’essor du SaaS et des architectures en microservices a rendu la communauté OS moins intransigeante sur les licences GPL. Le paysage évolue. L’« ouverture » passera peut-être de plus en plus par la volonté de documenter et publier des API, plutôt que par la distribution du code source à proprement parler. Dans tous les cas, nous préférons utiliser des technologies ouvertes.
Lectures recommandées
- CentOS — un projet communautaire de logiciel libre centré sur un écosystème open source robuste.
- Nginx — pour délivrer vos sites et applications avec performance, fiabilité et capacité de montée en charge.
- SilverStripe — le CMS intuitif et le framework flexible qu’adorent les éditeurs comme les développeurs.
- Varnish — un accélérateur d’applications web, aussi connu comme reverse proxy HTTP avec cache.
- Symfony — le socle standard sur lequel sont bâties les meilleures applications PHP.
- AngularJS — un framework front-end open source pour applications web.
- React — une bibliothèque JavaScript pour construire des interfaces utilisateur.
Le mois prochain : Agile, livraison, gouvernance robuste