Chez Otherside at Work, nous développons la Suite Xpert pour accompagner les organisations dans la gestion de l'absentéisme, l'employabilité durable et la sécurité sociale. La suite Xpert est une solution SaaS qui soutient les employés, donne aux organisations une emprise et connecte les partenaires de la chaîne. Sélectionner les bonnes technologies pour notre pile technologique est essentiel au succès et à la fiabilité de notre entreprise. Dans ces choix, nous croyons en une approche pragmatique : nous choisissons la technologie qui est la plus adaptée à la tâche spécifique. Dans ce blog, Stef Roskam, vice-président de l'ingénierie chez Otherside at Work, discute de notre vision de la construction de cette pile technologique. Le choix des logiciels open source et fermés et les considérations qui les sous-tendent sont au cœur de cette décision.

La gestion du cycle de vie : au cœur de nos choix

"Notre base de code est l'utilisation de toute notre entreprise. Compte tenu de la taille de la base de code, il n'est pas réaliste qu'elle puisse être complètement remplacée en une seule fois. Cela signifie que nous fixons des normes élevées pour les composants clés de notre infrastructure" , explique Stef. Ces composants doivent :

• Avoir une stratégie de mise à jour fiable.
• Offrez un risque minimal de dépendance vis-à-vis d'un fournisseur, par exemple grâce à des modèles de tarification prévisibles.
• Avoir fait ses preuves dans le domaine des mises à jour de sécurité et de la gestion du cycle de vie.

Stef poursuit : « En raison de ces exigences, nous choisissons des logiciels open source pour les composants cruciaux. L'open source nous donne la liberté et la flexibilité de répondre de manière appropriée aux changements des fournisseurs ou des mainteneurs, minimisant ainsi la dépendance à l'égard d'une seule partie.

La dépendance vis-à-vis d'un fournisseur : un élément clé pour les composants de base

Avec l'open source (avec les bonnes licences), vous évitez également le risque de dépendance vis-à-vis d'un fournisseur. La dépendance vis-à-vis d'un fournisseur peut présenter des risques importants, en particulier lorsqu'il s'agit de logiciels difficiles à remplacer. Stef donne un exemple : "Supposons, par exemple, que l'un de nos fournisseurs augmente soudainement les coûts de licence d'un montant considérable. Si nous ne pouvons pas passer à un autre système en raison du nombre élevé d'années-hommes pour remplacer (partiellement) la base de code, nous risquons d'être coincés avec des coûts élevés pendant des années. Pour gérer ces risques, nous utilisons l'open source avec de bonnes licences pour tout ce qui nécessite beaucoup d'efforts pour être remplacé. Les exemples les plus importants sont :

• .NET pour le backend.
• Bibliothèques JavaScript pour le frontend.

Pour tous les autres composants, ce qui suit s'applique : regardez ce qui convient le mieux

"Pour les pièces de notre pile technologique qui prennent moins de temps à remplacer, nous utilisons des considérations différentes. Pensez à des composants tels que les logiciels de sauvegarde, les composants utilisés localement dans notre plateforme SaaS, les pare-feu, les proxys et les plateformes d'hébergement", explique Stef. Pour ces utilisations, les éléments suivants sont évalués :

• La mesure dans laquelle la solution répond à nos besoins fonctionnels.
• L'effort de mise en œuvre des composants.
• Une sécurité que le fournisseur peut garantir.
• Réputation du fournisseur.
• L'accompagnement que le fournisseur peut offrir et à quel taux.

Sécurité: open source ou source fermée

"On suppose souvent que les logiciels open source sont plus sûrs parce qu'ils sont accessibles au public et peuvent être examinés par une large communauté. Dans la pratique, cependant, cette hypothèse ne s'applique pas toujours ", explique Stef. Il poursuit : "De nombreux projets open source sont maintenus par de petites équipes, voire par un seul développeur, ce qui peut limiter le niveau de contrôle et de développement. De plus, il existe de nombreux exemples d'open source qui ont montré qu'ils avaient des vulnérabilités. Il faut dire que les logiciels fermés ne sont pas nécessairement plus sûrs. Pour évaluer la sécurité d'une collaboration avec un fournisseur, les éléments suivants sont pris en compte, entre autres :

• L'expertise de l'équipe de développement.
• Les ressources disponibles pour la maintenance et le développement ultérieur.
• La qualité de la base de code existante.

 C'est pourquoi nous attachons une grande importance à la réputation et à la fiabilité du fournisseur ou de la communauté, que le logiciel soit open source ou fermé. »

Autres critères d'évaluation pour la sélection d'un logiciel

Stef explique comment notre approche de sélection de l'open source ou du closed source se caractérise par une évaluation critique, entre autres :

1. La stabilité et la pérennité du développement futur.
2. La qualité du code et le soutien de la communauté de développement ou du fournisseur.
3. Le risque que nous courons si un fournisseur cesse le support ou apporte des modifications.

Notre choix pour .NET en est un bon exemple. Bien que ce cadre soit open source, il offre une forte garantie de continuité grâce au support de Microsoft et à un large réseau d'utilisateurs. Avec des fournisseurs plus petits ou des technologies moins connues, nous effectuons des évaluations plus fréquentes et plus intensives pour avoir une certitude quant à la qualité et à la pérennité.

Conclusion : une approche équilibrée fonctionne mieux pour Otherside at Work

Stef conclut : Notre pile technologique est un mélange soigneusement sélectionné de solutions open source et fermées. Pour les systèmes centraux, nous choisissons les technologies open source en raison de leur plus grande flexibilité et de leurs risques plus faibles de dépendance vis-à-vis d'un fournisseur. Pour les autres composants, nous choisissons la solution qui correspond le mieux à nos besoins. Cette approche pragmatique nous permet de maintenir une infrastructure logicielle qui est non seulement fiable et sécurisée, mais aussi bien préparée pour les développements futurs.

Vous avez des questions sur notre vision de l'open source ou du closed source ? Ou vous voulez en savoir plus sur la façon dont nous envisageons notre stratégie technologique ? Par exemple, lisez ici notre vision du développement progressif par rapport à la reconstruction.  N’hésitez pas à nous contacter.