Un dicton français dit que l'on n'est jamais si bien servi que par soi-même. Ce pourrait être la devise de Yoctopuce, car nous sommes effectivement très attachés à réduire au maximum la dépendance de nos produits et de nos services à des tiers. Et pas sans raison, comme l'expérience nous l'a plusieurs fois montré, jusqu'à cet été où nous n'avons pas pu recevoir de paiements par carte de crédit en monnaies autres que le franc suisse pendant plus d'un mois...
Le fait est que nous aimons bien faire les choses entièrement nous-mêmes, de bout en bout. Que ce soit la programmation de notre site web ou de nos outils de back-office, la fabrication de nos modules ou le développement des librairies de programmation, quand il est matériellement possible de le faire nous-même de A à Z, nous préférons le faire. Certains trouveront cela inefficace, sous-entendu financièrement inefficace, mais c'est pour nous la manière la plus naturelle de garantir la qualité de nos services. Non pas parce que nous pensons faire mieux que les autres, mais parce qu'en faisant les choses nous-mêmes,
- nous nous mettons à l'abri des modifications non désirées qui se produisent hors de notre contrôle;
- nous préservons au sein de l'entreprise des compétences nécessaires pour offrir un support de qualité;
- nous portons directement la responsabilité de nos produits face à nos clients, et pouvons corriger les problèmes sans délai, dès que nous les découvrons ou qu'ils nous sont signalés.
Fabrication locale
Bien que l'assemblage de nos produits pourrait facilement être exporté pour en baisser les coûts, nous tenons à la maintenir chez nous. En premier lieu, c'est la seule manière d'être vraiment sûr de comment ils sont fabriqués. En inspectant un produit fini, il est quasiment impossible de savoir si les courbes de température de cuisson ont vraiment été respectées, si un composant n'a pas été remplacé par une contrefaçon moins chère ou si les condensateurs sont bien les modèles de la qualité prévue. Les produits électroniques grand public regorgent de ces composants bons marchés officiellement spécifiés "for consumer device only", qui survivent beaucoup moins bien dans la durée que des composants de qualité industrielle.
Economiquement, il y a aussi des avantages à assembler nos produits nous-même: on peut se permettre de fabriquer les produits par petits lots, de taille variable selon la demande. Lorsque les stocks d'un produit baissent trop, on relance une production le lendemain, et on maintient ainsi des délais de livraisons optimaux pour nos clients. Nos outils fait-maison de surveillance de stock remplacent avantageusement des montagnes de produits finis en attente d'être vendus.
Mais il n'y a pas que sur le matériel que nous préférons faire les choses nous-même...
Réutilisation de librairies tierces... ou pas
Il n'y a pas si longtemps, réécrire soi-même du code qu'on pouvait trouver prêt à l'emploi sur internet était présenté par certains comme un péché. Le code partagé par d'autres sur GitHub, ayant été relu et amélioré par de nombreux utilisateurs, devait forcément être meilleur que celui qu'on peut faire soi-même, même pour les tâches les plus élémentaires.
Appliqué à outrance, ce principe a conduit à la multiplication de packages ridiculement simples, et surtout à l'apparition de librairies avec des dépendances tentaculaires. La conséquence, totalement prévisible, a été la multiplication exponentielle du nombre de contributeurs à des librairies très utilisées, et donc une augmentation dramatique la surface d'exposition au risque d'injection de code mal intentionné. A ce jour, la page officielle de GitHub qui répertorie les packages dans lesquels du code malveillant a été détecté, comporte plus de 50'000 entrées...
Les méga-pannes et piratages causés par ce phénomène de réutilisation de code non maîtrisée nous ont conforté dans notre approche de toujours privilégier le code "fait maison". Les rares exceptions que nous avons tolérées sont des librairies qui n'ont elles-mêmes aucune dépendance, et pour lesquelles nous avions une raison de ne pas les recoder nous-même:
- Mbed TLS: le risque de qualité sur la réécriture d'une librairie de cryptographie est largement supérieur au risque intrinsèque de cette librairie, compacte, sans dépendance externe et maintenue par une équipe professionnelle;
- ws: nous avons choisi depuis quelques années d'utiliser cette librairie quasi standard pour le support WebSocket sous Node.js; mais nous pourrions bien décider de nous en passer prochainement, puisque nous avons déjà réécrit le support WebSocket pour plusieurs autres langages.
Mis à part ces deux exceptions, nous n'utilisons dans nos librairies de programmation que les librairies de base fournies par le langage lui-même, et nous tenons à coder nous-mêmes le reste.
De même, dans le firmware de nos modules, nous ne réutilisons telles quelles que quelques librairies de base fournies par le fabricant du processeur, mais nous réimplémentons à notre manière tous les composants importants, afin d'en garder le contrôle complet.
L'approche qui consiste à tout coder soi-même autant que possible a deux autres avantages qui ont souvent été sous-estimés:
- elle rend le job du développeur passionnant
- elle maintient ses capacités intellectuelles au niveau nécessaire pour permettre un support de qualité.
Il a fallu l'arrivée de l'IA ces dernières années pour que l'on commence à réaliser que déléguer le développement des éléments clés à un tiers, artificiel ou humain, c'est choisir de perdre des connaissances à relativement court terme. Et il n'est probablement pas anodin qu'on doive désormais avertir les étudiants que s'ils utilisent une IA à la place de faire les choses eux-mêmes, ils perdront le goût du travail.
Mais même si nous aimons bien tout faire nous-mêmes, nous ne pourrions pas vendre nos produits à travers le monde sans faire appel à quelques services informatiques fournis par des tiers...
Utilisation de services externes
Pour maintenir à l'heure vos modules connectés par Internet, nous collaborons avec NTP Pool Project qui offre le service NTP à travers le monde. C'est un service que nous n'aurions pas pu monter tous seuls avec la même qualité. Mais vous n'êtes pas forcés d'utiliser ce service NTP, vous pouvez bien sûr configurer vos hubs pour utiliser votre propre serveur NTP si besoin.
Pour faciliter l'utilisation de nos librairies, nous les publions sur GitHub et sur différents systèmes de distribution de package comme npm, PyPi et NuGet. Mais vous avez toujours la possibilité de venir télécharger vos librairies directement sur notre site web, sans passer par des sites tiers.
Notre site web, justement, est hébergé chez un prestataire internet local. Il fait bien son travail, nous fournit amplement de bande passante et se charge de maintenir constamment le système d'exploitation de notre serveur au niveau de sécurité nécessaire, mieux que nous ne pourrions le faire nous-même.
Pour accepter les paiements par carte de crédit sur notre site, la réglementation nous impose de passer par un prestataire externe accrédité, sujet à des audits de sécurité poussés. Et là, il faut admettre qu'on a pas été très bien servi cet été, et qu'on aurait clairement préféré être maîtres de la situation comme pour le reste...
La saga des paiements par carte de crédit
Pour faire court: début juillet, suite à un changement dans les modalités du contrat avec notre prestataire d'acceptation de cartes de crédit, celui-ci a effectué sans nous en informer un changement dans la configuration de notre compte. Ce changement a conduit à systématiquement refuser les paiements par carte de crédit en monnaies autres que le CHF (franc suisse). Tous les paiements en Euro et US Dollar échouaient systématiquement. Nous avons eu beau enchaîner les messages par mail et par téléphone au support pendant plus d'un mois, impossible d'obtenir du prestataire qu'il rétablisse la situation.
Nous avons finalement dû basculer vers un autre prestataire d'acceptation de cartes de crédit, plus crédible dans la maîtrise de son infrastructure. Après 40 jours d'interruption - et après avoir implémenté une nouvelle passerelle avec ce prestataire dans notre shop, nous étions fin prêts pour la rentrée.
Nous sommes désolés pour tous ceux qui se sont heurtés à ce problème cet été et vous présentons nos excuses pour le désagrément.
