BSP MIC 1 02:
Faire du self-hosted aujourd'hui, c'est un peu comme s'installer dans un penthouse à Dubaï, sans avoir la clim, sans avoir la fibre, mais avec une armée de Raspberry Pi et la promesse que rien ne sera plug and play. Au début, on se dit que ça va tourner et que ça va rouler sans problème. Une infra, quelques services on-prem, c'est easy. Et puis au final, on découvre que chaque redémarrage prend des plombes, que Kubernetes s'est un peu surcoté pour un environnement où la performance se mesure en cycle de CPU économisé plutôt qu'en pod déployé et que tout devient un tuning hardware jusqu'au kernel en custom. Mais alors, pourquoi persister dans le self-hosted à l'heure où tout le monde jure par le SaaS et le cloud pour nous sauver ? Jusqu'où faut-il tout réécrire pour tenir ces contraintes et surtout, combien de café faut-il boire pour vouloir réinventer la roue ? Pour répondre à ces questions de reconstruction, je ne reçois pas MacGyver mais il sait recoller un cluster avec un chewing-gum et une épingle à nourrice. Loïc, bonjour.
BSP MIC 2 02:
Bonjour.
BSP MIC 1 02:
Alors Loïc, est-ce que tu pourrais te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
BSP MIC 2 02:
Je m'appelle Loïc Tosser, Wowie42 sur les réseaux. Je suis entrepreneur à Dubaï, tech, pure tech. Je suis un 6 ennemis d'un barbu. J'ai moins de barbe aujourd'hui, mais d'habitude, j'en ai un peu plus. J'ai passé les 11 dernières années à Dubaï. Et là, je suis rentré en France maintenant. Je bosse aussi avec des voix de françaises qui sont très bien connues. Bonjour Clever Cloud. Je bosse un peu avec eux aussi. Et puis voilà, je suis 6-admin, j'aime beaucoup le Python, l'erlangue, le C, j'aime pas trop le Rust, voilà, je le dis officiellement, je vais me faire taper mais bon voilà, et puis voilà.
BSP MIC 1 02:
Donc du coup t'es arrivé à Dubaï, pardon ? Et tu as eu une idée assez folle de vouloir recréer des services qui pourtant existaient déjà chez d'autres sur du hosting. Est-ce que tu peux nous raconter un peu comment est-ce que tu as eu ces idées-là et qu'est-ce que ça t'a amené en fait à faire et à recréer ?
BSP MIC 2 02:
En fait, ce n'était pas une idée, c'était une nécessité. Dans le sens où en fait, quand je suis arrivé à Dubaï, il n'y avait pas de cloud provider. Il n'y avait pas WS, il n'y avait pas GCP il n'y avait pas Azure et en fait le cloud provider le plus proche était à Singapour, donc on avait 150 millisecondes et on passait de l'autre côté du globe, et donc en fait qu'est-ce qui se passe c'est que quand tu commences à avoir 300 millisecondes de latence avec l'Europe, 450, 500 millisecondes avec les Etats-Unis, tout prend du temps que ce soit ton GitHub, que ce soit ton monitoring, ton datadog ton Splunk, enfin voilà, et donc en fait à la base on a fait ça parce qu'on en avait besoin parce qu'en fait on ne voulait pas attendre tout le temps, on voulait avoir du cash localement quand tu fais un NPM install en Europe déjà ça te fait mal parce que tu prends 2Go dans les temps mais quand tes 2Go ils arrivent à 100kbps, ça fait encore plus mal, donc c'est comme ça qu'on est arrivé au départ pour remplacer, Et quelques années après, bien sûr, AWS et Azure sont arrivés. Et on a vu un shift progressif vers ces plateformes-là. Mais nous, en fait, on s'est dit, ça nous coûte cher. Et en fait, on a l'habitude. Si on continuait à self-hosted, et on va continuer, on va continuer, on va continuer. Et en plus, nous, on bosse dans un milieu qui est très régulé. Donc, aller mettre des données sur des clouds américains, il y en a qui n'étaient pas chauds.
BSP MIC 1 02:
Tu bossais dans quel domaine ? C'est quoi ce...
BSP MIC 2 02:
La CETAN-CIO bosse beaucoup avec le gouvernement des Émirats. Et des institutions financières donc c'est très très, régulé, ils ne veulent pas que leur data soit n'importe où donc on est par exemple aussi sur des data centers donc nous on a notre propre data center, on a des serveurs à notre bureau, mais on a aussi on doit aller dans des data centers gouvernementaux tu peux même pas rentrer, je vais te mettre tout nu tu retires tous tes habits, tu mets une combinaison orange dans laquelle je ne rentre jamais et après tu vas au roi d'aller dans le data center pour aller travailler sur les serveurs.
BSP MIC 1 02:
Donc.
BSP MIC 2 02:
C'est vraiment un truc très très régulé.
BSP MIC 1 02:
Je comprends que tu te dis il n'y a rien qui n'existe donc il faut qu'on fasse les choses nous-mêmes, mais quand tu essaies de reproduire ce que des AWS ou Google font on ne va pas se mentir, c'est quand même des boîtes qui ont une échelle colossale, tu as beaucoup de gens qui pourraient se dire en fait on n'est pas capable d'aller s'attaquer à ces problèmes là.
BSP MIC 2 02:
On n'est pas capable de je ne peux pas recoder un AWS, c'est pas possible mais par contre Parce que j'ai d'autres contraintes aussi. Il faut bien se rendre compte que vu qu'on bosse beaucoup dans du régulier, je suis dans des data centers où j'ai un espace fini, des ressources finies. J'ai par exemple sur un virtual data center, je vais avoir 600 gigas de RAM. Si j'ai besoin de 650, je ne peux pas le faire. Je ne peux pas les demander 50 gigas de plus. Il faut que j'aille faire quatre formes, que je vais les signer, contre-signer, donner un litre de mon sang pour que je puisse le signer aussi. C'est énormément de travail donc en fait notre travail aussi c'est de rendre la tech plus plus économe, Et donc, on change énormément de paradigmes. Parce que quand tu as les ressources dans AWS, c'est vrai, ils rackent énormément de serveurs. Donc, en fait, ils ont un schéma de pensée, même un schéma de développement de leurs produits qui est vachement différent. Nous on est très restreint et donc ça change et donc on ne peut pas faire un AWS local mais par contre on peut réécrire un certain nombre de briques qui vont nous permettre de délivrer des services de qualité, pour nos clients ou en open source d'ailleurs et en gros c'est vachement plus intéressant d'aller. Sur ce chemin là pour nous et ça nous a donné beaucoup de compétences aussi, parce que tu vois par exemple tout le monde nous dit il faut aller faire du BigQuery je vais cracher sur tous les clés américains Je vais commencer par Google. BigQuery, c'est génial. C'est vrai, enfin, il n'y a pas de... Bon, par contre, quand tu commences à faire mumuse et que tu es un peu un gros porc dessus, où tout le monde balance de la data un peu n'importe comment, tu fais une query, ça te coûte quoi ? 10 balles, 50 balles, 100 balles ? Ça commence à chiffrer. Alors que nous, on va penser de manière différente. On va dire, quand la data arrive, il faut déjà qu'elle soit propre. Il faut qu'on est cligné en avance. Donc ça fait qu'on stocke beaucoup moins. On compresse énormément. On a beaucoup de gestion de la data qui est hot, qui est cold, qui est frozen. Vraiment, on se sépare par tiers. Et donc ça fait qu'en fait, nous, on est capable d'avoir plusieurs databases ou des databases plus petites, compressées, qui nous permettent vraiment d'avoir des performances qui ne sont pas dégueulasses.
BSP MIC 1 02:
Ce que je trouve aussi assez complexe dans ce que tu décris c'est qu'effectivement toi tu as un contexte qui est hyper fini, qui est hyper limité mais l'idée c'est que tu fournisses quand même un service aussi à des gens qui eux n'ont peut-être pas cette, envie d'être cloisonnés, qui ont peut-être l'habitude de déployer des choses sur AWS et de se rajouter effectivement de la machine un peu sans ticket, donc toi il faut que tu leur fournisses, un contexte qui est visiblement infini en faisant en sorte que toi, tu tiennes dans tes limites, quoi. Il y a un peu de ça, non ?
BSP MIC 2 02:
Il y a un peu de ça, mais en fait, s'il y a un truc bien plus intéressant, c'est le coût. Là, je veux dire, tous les entrepreneurs, toutes les boîtes, ce qui les intéresse, c'est que moi, ça leur coûte. Je vais te donner l'exemple de GitHub Runner. Je ne sais pas si tu... Donc, GitHub, ils ont une CI avec les GitHub Runners et GitHub Actions qui, quand tu les prends dans le cloud, sont payantes. C'est normal. Et tu peux faire des self-hosties de runner. C'est-à-dire qu'en gros, tu prends tes GitHub Actions, tu prends ton runner, tu le mets sur tes serveurs dans ton environnement, que ce soit ton environnement cloud ou local, et ils vont te l'exécuter pour toi. En gros, tu t'intègres dans la CI de GitHub. Le problème, c'est que GitHub vient de dire qu'ils allaient les facturer. Ils ont dit ça il y a un peu plus de trois mois. Mais nous, on avait anticipé ce mouvement-là. Et en fait, quand GitHub a dit on va les facturer, nous, tous nos clients ont dit attends, là, c'est-à-dire que là, on va facturer, on va prendre quoi ? 4000 balles en plus par mois chez GitHub. Bon, alors, lui, oui, on trouvait que tu étais un peu cher par rapport à l'époque. Maintenant, ça va. Et donc, en fait, la décision, elle est simple. C'est vraiment ça. Et en plus, on a aussi une question de temps. Quand tu as envie, par exemple, que tu aies ton infrastructure qui est localement dans le Golfe en général... Comme je te l'ai dit tout à l'heure, en fait, tout passe par ou l'Europe ou les Etats-Unis. Et donc, en fait, si tu n'as pas un niveau de cash au milieu, en interne de ton entreprise, tout ralentit. Ton bulle de CACD va pouvoir prendre 25, 30, 40, 55 minutes, une heure. Alors qu'avec du bon cash intelligent, je précise sur le intelligent, en fait, en 5 minutes, tu es plié. Et donc, ça fait que c'est vraiment, vraiment beaucoup plus intéressant.
BSP MIC 1 02:
Ça a été quoi les premiers gros challenges techniques que tu as rencontrés ?
BSP MIC 2 02:
— La qualité d'Internet là-bas.
BSP MIC 1 02:
— Ouais.
BSP MIC 2 02:
— Ouais. Il faut bien se rendre compte que les Émirats, typiquement, sont un pays très très jeune. Ils ont un peu plus de 50 ans maintenant. Et qu'ils n'avaient pas le France Télécom que nous, on a eu. Ils n'avaient pas l'infrastructure. Donc ils développent en temps réel. Et par exemple, ils disent « Bon, ben voilà. Là, on va mettre un gros corps network sur cette partie-là de Dubaï. en fait cette partie à Dubaï a explosé, il y a dix fois plus d'habitants que prévu donc tes tuyaux ne passent plus et donc faut en remettre et tout ça. Ça c'était vraiment un de nos plus gros problèmes. Il y avait aussi le prix de la bande passante, enfin en France, pour quoi 35 euros t'es une fibre gigabit, là-bas en pro pour une fibre gigabit faut plutôt compter dans les trois quatre mille euros minimum par mois, donc t'avais ça aussi. Mais après encore une fois tout est une question de balance. Quand tu... Je vais te donner l'exemple de la fibre pour les bureaux, par exemple. Quand tu te dis, voilà, nous, on paye 300 Mbps pour nos employés qui viennent au bureau, OK ? Si, en fait, tu dis, il y a 50 Mbps qui vont tout le temps partir sur les installations NPM, Maven, PayPay, ou ce que tu veux, tous ces logiciels-là, en fait, tu limites les capacités de tout le monde. Alors que si tu mets un cache devant, en fait, il y en a un qui va le taper une fois, et puis les autres, d'ailleurs, ils vont taper dans le cache. Et donc, en fait, on a beaucoup de tricks comme ça qui vont vraiment réduire les factures et aussi améliorer l'expérience des développeurs. C'est ça le plus important pour nous aussi. Moi, j'ai une société de service. Mon principe, c'est que mes développeurs produisent. Si à chaque fois, même en faisant du Python, c'est comme du Java, ils attendent que ça télécharge et ils n'auront rien à faire, je perds de l'argent.
BSP MIC 1 02:
Donc voilà ce qui est intéressant c'est que toi tu te retrouves à créer un écosystème c'est à dire que si on reprend l'exemple de la WS, ils ont bien évidemment un ensemble d'ingénieurs dans leurs équipes qui eux aussi en fait vont créer des services mais avec une capacité de déploiement, une capacité d'échelle qui est phénoménale là où toi tu dois réussir à trouver un service alors forcément pas forcément au même niveau de qualité mais en tout cas un système à peu près équivalent en termes de, sur des éléments fondamentaux et nécessaires à toute organisation. Mais toi, il faut que tu fasses du coup dans un contexte beaucoup plus réduit. Est-ce qu'on pourrait du coup comparer ça à des gens qui font de l'embarqué et qui du coup ils ont une petite batterie, un tout petit processeur. Enfin tu vois, ils ont ces mêmes contraintes de dev au final.
BSP MIC 2 02:
C'est un peu ça oui, parce qu'en fait, comme je l'ai dit, on se trouve dans des environnements qui ne sont pas finis, enfin qui sont finis pardon, contrairement à AWS. Et donc nous on n'a pas le choix, il faut qu'on soit propre. C'est si, à un seul coup, tu as 100% d'utilisation de RAM, je fais quoi ? Moi, je suis mort. Je ne peux pas aller popper un pod sur le côté. Non. Donc, vraiment, il faut faire très, très attention. Que ce soit l'utilisation, c'est ça le plus intéressant, de la RAM, du CPU, tu t'y attends en soi. Il y a le disque aussi et tu as l'IO. Quand tu commences à faire du self-hosted, ta bande passe sans te nettoie contre tes serveurs, commence à devenir importante. Donc typiquement, si tu dis, je vais mettre du gigabit par seconde, donc un petit réseau, et puis qu'en fait, tu dois restaurer une DB qui fait, je ne sais pas, 200 Tera, En fait, 200 Tera à passer sur un gigabit, ta restauration va mettre du temps. Donc tu vois, tu as tout ce genre de problème, mais qui vient au fur et à mesure. Et ça fait que tu as une vision, je trouve, beaucoup plus saine et on fait beaucoup plus attention. Par exemple, dans notre CI-CD, on a beaucoup de tests de performance aussi. C'est vraiment un truc qui fait très attention. On moniteur excessivement, intensément la performance de nos applications. Le meilleur exemple que j'ai, c'est sur nos requêtes HTTP. On fait beaucoup d'HTTP quand même. Enfin, on a beaucoup d'exposures HTTP. Bon, donc, tu as des requêtes HTTP qui arrivent. On va monitorer le temps de latence. À quel moment ça arrive ? Est-ce que ça vient par package ? Quelle est la source aussi ? Et donc, en fait, nous, on va calculer, par exemple, notre SLA et notre SLO. On va le calculer à la fois sur notre temps de réponse, mais aussi sur notre taux de disponibilité. à la place de dire nous on a 99.99. Mais c'est juste si on crache en journée par rapport à un crash en nuit l'impact est complètement différent donc on compte en fonction du nombre de requêtes, et donc ça nous donne des métriques qui sont vachement différentes du reste du monde et par exemple tu vois c'est comme ça que il y en a qui disent ah non on a 99.99 de disponibilité sur notre service c'est vrai, en temps par contre si ça crache au moment où moi je fais une vente et j'ai un pic de vente, bah je fais la gueule Et donc là, nous, on va plutôt monitorer ça. On va faire beaucoup plus attention là-dessus.
BSP MIC 1 02:
— Là, je vois. Tu évoques toutes ces contraintes d'espace divers et variés qui peuvent se présenter ? Tu dis que vous essayez d'anticiper de faire attention, d'être vigilant à quel point est-ce que, tout cet apprentissage que vous avez aujourd'hui sur la mesure de la performance sur essayer de tenir les trucs, à quel point c'était des choses que vous avez déjà anticipées quand vous aviez commencé le projet versus ce que tu découvres où tu fais attends merde là en fait c'est en train de péter ah bah en fait le problème vient là donc maintenant à l'avenir, tu vois ce que je veux dire.
BSP MIC 2 02:
À quel.
BSP MIC 1 02:
Point l'apprentissage est dans la douleur.
BSP MIC 2 02:
Dans le sang et les larmes on arrive à anticiper des choses je ne vais pas te dire qu'on n'arrive à rien anticiper mais il y a des choses qu'on n'avait pas du tout anticipé tu ne peux pas en fait, tu vois tu as ton process à la fin ce qu'on fait nous avons construit des processus que ce soit au niveau dev ou au niveau devops même pour nos clients bon bah t'as un processus on va restaurer l'ADB bon bah on a un book nous on fait beaucoup de pain fra pour ceux qui connaissent, en gros c'est un ansible qui marche bien je troll un peu mais voilà Eh bien, en fait, qu'est-ce qui va se passer ? C'est qu'on va l'exécuter localement, on va faire des tests. Ah, ben, ça marche, le code est bon. Ah, et on va essayer de stopper l'ADB au milieu du process. Qu'est-ce qui se passe et tout ça ? Mais tu n'anticipes pas, par exemple, le réseau. Tu ne te dis pas, attends, on vient de saturer le core network de notre provider, qui a de l'hyperconvergé. Je ne sais pas si tu sais ce que c'est l'hyperconvergé. OK. Quand tu fais un data center, typiquement, en fait, qu'est-ce qui se passe ? Tu vas voir ton réseau, ton stockage et ton compute. OK ? Et en fait, l'hyperconvergence, c'est de dire, à la place de bien séparer proprement, tu as ton corps réseau en Cisco, tes serveurs Dell et tes SANs Dell aussi, et bien en fait, tu vas un peu tout mettre ensemble et tu vas te dire, bon, en fait, je vais être beaucoup plus dynamique. Alors, c'est très intéressant parce que ça peut même utiliser des ressources. Le problème, c'est que quand tu commences à saturer le cœur de ton réseau, En fait, tu satures tout à la fois.
BSP MIC 1 02:
Parce que du coup, c'est que tu utilises une partie de tes machines comme étant des machines réseau et inversement. Et du coup, si tu en satures un, tu as moins de place pour l'autre.
BSP MIC 2 02:
Et généralement, après, ça fait un super effet domino. Et par exemple, la bonne idée qu'ont beaucoup de gens qui font des hyperconvergences, c'est de se dire j'ai hyperconvergé tout ça et je mets en plus mes load balancer et ma solution de sécurité dedans. En fait, quand tu en as un qui sature, tout sature et là, tu exploses. Et là, tu prends un downtime. Et c'est ce qu'on a eu. D'ailleurs, je parle d'expérience. Donc ça, ça te donne des résultats qui sont très très mitigés et donc voilà il faut anticiper tout ce genre de problèmes.
BSP MIC 1 02:
Dans la notion de hosting on a aussi une obligation d'observabilité, c'est à dire que les gens qui sont hostés ils ont quand même besoin de surveiller ces choses là, comment est-ce que toi tu le fais pour leur donner des indicateurs qui te permettent parce que j'imagine que tu dois leur donner des contraintes aussi liées à ton écosystème à toi en fait. Et donc il faut que tu aies peut-être des indicateurs qui ne soient pas ce qu'on va retrouver chez un AWS ou chez un Azure.
BSP MIC 2 02:
Alors de quel type d'indicateur tu es en tête ?
BSP MIC 1 02:
Tout ce qu'on peut voir sur l'observabilité de manière assez classique.
BSP MIC 2 02:
Alors en fait on a plusieurs niveaux d'observabilité. On va vraiment marcher en plusieurs niveaux parce que il faut bien se comprendre que mes clients en face ne sont pas tous des techs. Des fois c'est des gens qui ne connaissent littéralement rien à la tech. Mais ce qu'ils veulent aussi savoir c'est si le système marche. Donc en fait on va avoir trois niveaux de communication et d'indicateurs. Le premier, c'est est-ce que le système marche ou pas ? Et si ça ne marche pas, on envoie un email, une notification, un SMS, un WhatsApp. Le deuxième, c'est qu'on va essayer de leur montrer comment le système va évoluer. Mais ça va être une vision très, très simpliste, à la limite, tu vois. Et on a la vision 3, où là, ça va avoir des indicateurs en profondeur, en performance. Ça va être, par exemple, quel est notre latence réseau sur tout le réseau. On va aller vraiment sur beaucoup plus de la profondeur. Ça va être aussi, par exemple, on va détecter des erreurs de RAM. C'est comme ça qu'on a détecté, par exemple, que certains cloud providers, on va dire sérieux, n'utilisaient pas de l'ECC, par exemple. Quand tu commences à prendre un bitrot sur ta RAM, sur une DB, bon, ça te fait un peu bizarre quand même, parce que tu n'anticipes pas ça non plus. Et donc là, tu vois, là, on va vraiment aller dans la profondeur et on va communiquer là-dessus. On va essayer de remonter l'information aussi pour que les gens comprennent. On a une grosse partie d'éducation aussi.
BSP MIC 1 02:
— Et sur la partie évolution, comment tu fais en fait pour... C'est quoi ? C'est essayer de prédire les dérapages possibles ou c'est tu fais une simple régression linéaire sur ce que tu vois sur le passé ? C'est pour donner une idée aux gens de l'évolution de facture ? Enfin tu vois, c'est le...
BSP MIC 2 02:
— Il va y avoir un peu de ça, mais c'est surtout aussi sur les features qu'ils vont rajouter. Tu vois, par exemple, nous, on a un de nos systèmes qu'on a développé. Là, c'est un truc custom, mais c'est un self-hosted aussi pour nos clients, qui va faire une analyse de toutes les transactions qui se passent dans toutes les instances du gouvernement d'Azimira. Et en fait, à un moment, ils disent qu'on aimerait avoir une nouvelle vue et qu'on pré-calcule énormément de data. Et en fait, ça, ça fait qu'on doit anticiper que si on pré-calcule tout ça, ça va nous utiliser tant de stockage. Donc, en fait, à chaque fois qu'on a une nouvelle demande de feature, on ne fait pas seulement un document technique dans le sens où tu l'entends, où il y aura feature A, feature B, feature C, et voilà les technologies qu'on va utiliser. On va avoir aussi un calcul de combien ça va nous prendre à l'instant T où on va le lancer, quelle va être l'évolution à un ou deux ans, et quelle est l'efficacité, entre guillemets. Tu vois, par exemple, s'ils nous disent « on va voir un dashboard, mais il va servir une fois par semaine », bon, en fait, s'il met trois minutes à charger, ou si on peut l'envoyer en asynchrone, pas de problème. Par contre, si c'est censé être dans des télés, dans, je sais pas, je vais dire, 30 entités du gouvernement... Et qui recharge toutes les 30 secondes, là t'as intérêt à avoir quelque chose qui soit un peu plus rapide, donc on va mettre des niveaux de cache. Et donc tout ça en fait on essaie d'anticiper et de dire ok alors ça et là on revient au tiering de la data, on a du très hot, du cold et du frozen tu vois et donc c'est comme ça qu'on se calcule.
BSP MIC 1 02:
Et donc en fait vous faites pas que une offre d'hébergement où les gens ils peuvent mettre leur application quelle qu'elle soit, vous êtes aussi là en fait pour fournir l'application en tant que telle ?
BSP MIC 2 02:
Oui, des fois aussi, on fait de tout, en fait. Mais on fait vraiment sur des trucs qui sont hyper réguliers. C'est des gens qui vont voir, j'ai une application, comment je fais pour qu'elle soit hostée aussi ? En sécurité, on fait beaucoup de sécurité aussi, parce que malheureusement, les Emirates sont une cible prioritaire pour beaucoup de pays, et donc nous, on les aide aussi. On n'est pas des experts en super sécurité, mais on aide à mettre en place des processus, par exemple, principalement dans la CICD, en disant, ouais, alors là, t'as déconné, là, cette requête-là, en fait, elle est trop lourde. Tu vois, typiquement, c'est à la place d'aller charger sans éléments sur la page d'accueil on va dire charges en 20, Et après, tu fais plusieurs refreshs et ça fait plusieurs requêtes. Et donc, tu réduis la charge.
BSP MIC 1 02:
Et du coup, sur ces notions de cyber, j'imagine qu'il y a aussi des apprentissages marquants. Parce que du coup, tu travailles effectivement avec des acteurs gouvernementaux qui ont des contraintes un peu sérieuses, on va dire.
BSP MIC 2 02:
Un peu, oui. On a pris beaucoup d'attaques. Il y en a qui sont passées, je ne vais pas mentir. Malheureusement, je touche du bois quand même pour que ça n'arrive pas souvent. Mais des fois, on a pris des zéro d'ail et là, c'est tout. On patch, on récupère on restaure, ça nous a fait aussi apprendre beaucoup de règles de sécurité qui sont plutôt inconnues du reste du monde parce qu'en fait il y a beaucoup de choses, tu parlais d'AWS typiquement il gère beaucoup de choses en background tu vois l'IAM en fait, ça peut être touffu, ça peut être complexe t'apporte une certaine sérénité si tu le configures bien, nous on n'a pas d'IAM, on n'a pas le même niveau d'IAM que, alors comment on fait pour faire, de la rotation de secrets comment on fait pour gérer nos secrets, comment on fait pour avoir du vault et tout ce genre de produit, donc ça nous donne énormément de nouvelles contraintes et beaucoup d'apprentissage. Et c'est ça qui est génial aussi.
BSP MIC 1 02:
C'est que... Mais en fait, d'autant plus que vous êtes obligés de les avoir, parce que vu les acteurs avec lesquels vous travaillez, tu peux pas faire sans, en fait.
BSP MIC 2 02:
Il y a ça, et il y a surtout que nous, on a de plus en plus de restrictions sur quelles compagnies on a le droit d'utiliser. Tu vois, par exemple, il y a des fois où je préfère faire de l'open source de manière générale, il faut être clair. Des fois, il n'y a pas de produit open source qui marche. Nous, on n'a pas le temps ou le budget pour le développer, donc on va aller chercher une boîte tierce, généralement américaine, malheureusement, et on va les mettre en place. Mais en fait, de plus en plus, on n'a pas le droit de le faire. Ils veulent vraiment gagner en souveraineté, qui est un mot très utilisé ces temps-ci, en particulier en France, avec l'autre aux cheveux orange, là. Mais c'est un vrai problème. Et donc, c'est comment tu fais pour aller de l'avant ? Comment tu fais pour construire tes solutions de sécurité ou tes solutions de monitoring ou tes solutions de management ? Là, on en parlait en off juste avant, AWS Dubaï est tombée depuis le 1er mars 2026, Il n'est pas remonté et ils ne savent pas quand est-ce qu'il va remonter. Il y a une dépendance technologique forte. Donc il y a beaucoup de systèmes des Emirats, alors plutôt des boîtes privées quand même, qui ne marchent plus maintenant. Et ils n'arrivent pas à extraire leur backup. Ils ont vraiment énormément de mal. Donc en fait, une dépendance technologique forte, c'est bien, dans certains cas, parce que ça te provide une certaine scalabilité. Mais il faut être capable aussi de se lancer ailleurs. Le multicloud dont tout le monde parle, il faut être clair, personne ne le fait pour de vrai. Je n'ai rarement vu qu'il marche vachement bien. Voilà.
BSP MIC 1 02:
— Oui. Et puis, du coup, c'est dans des situations un petit peu extrêmes, parce que là, la situation est un peu compliquée, qui fait que tu découvres, en fait, le poteau rose ou des vraies complexités, où tu te dis, en fait, j'ai pas besoin de prévoir ça, parce que ça n'arrivera jamais. Mais du coup, le jour où ça arrive, t'es un peu dans la panade, quoi.
BSP MIC 2 02:
— Oui. Par exemple, il y avait une banque que je ne nommerai pas, mais ils étaient tous en self-hosted, sauf leur authentification, qui passait par un acteur tierce qui avait dit que non, ils n'étaient pas sur AWS. AWS est tombé, les mecs sont tombés. Donc là, tu fais, attends, il y a un problème légal, clairement, mais t'as aussi un problème de shadow IT, t'as un problème de, attends, est-ce que je peux faire confiance à mes providers aussi ? Parce que les mecs ont menti. Donc, voilà, c'est un peu compliqué.
BSP MIC 1 02:
Quand on préparait cet épisode aussi dans les sujets qu'on a évoqués et que je trouvais intéressant, c'est que forcément qui dit hébergement cloud on pense cluster on pense containerisation, on pense forcément du coup cube à aujourd'hui t'as un avis certain sur cube oui.
BSP MIC 2 02:
D'ailleurs c'est comme ça qu'on s'est rencontré.
BSP MIC 1 02:
À la base c'est.
BSP MIC 2 02:
Parce que j'ai dit que Kubernetes c'était inutile, je crois que c'est ça que j'avais dit dans ces mots là c'est peut-être un peu plus hardcore que ça Mais oui, en fait. J'ai un avis là-dessus qui est beaucoup moins tranché que ce que j'ai dit à l'époque, mais c'est en fait que Kubernetes est une technologie intéressante, si elle est bien utilisée et dans certains cas, comme beaucoup de technologies. Quand tu prends MongoDB, par exemple, que tout le monde crache dessus quand même allègrement, MongoDB marche très bien dans certains cas. La Kubernetes, c'est la même chose. Le problème, c'est que les gens veulent mettre du Kubernetes absolument ou des fois, ils n'en ont pas besoin. Et c'est là où nous, on donne beaucoup de leçons, ce serait peut-être un bien grand mot, mais en disant, écoutez les mecs, si vous prenez 2000 requêtes par seconde, en fait, ce n'est pas grand-chose, il n'y a pas besoin d'un cube pour faire ça. Il y a d'autres manières de le faire. On peut aussi simplifier la stack. Kubernetes, en lui-même, il couvre un petit scope. Kubernetes, tu as besoin aussi de ton réseau, de tes policies, de tout ça, de ta CI-CD. Nous, on va essayer de simplifier tout ça. Parce que c'est, encore une fois, on a une contrainte à la fois technologique et des ressources. Et que Kubernetes est quand même très gourmand, mais on a aussi une contrainte humaine. Quand moi je recrute, il faut que les gens soient accrédités secret défense. Donc il n'y en a pas beaucoup. Et des 6 admins en plus, alors là encore moins. Et donc si j'ai besoin de les prendre et de leur passer 6 mois, que je leur explique comment marche Kubernetes et qu'est-ce qu'on a fait et tout ça, je perds trop de temps et donc trop d'argent. Et donc en fait on préfère rationaliser, un peu garder en mode « keep it simple, stupid », Et au moins, nous, on est beaucoup plus sereins aussi sur le niveau du monitoring, par exemple. Débuguer un Kubernetes qui part en vrille, c'est vraiment chiant. Alors que nous, débuguer, ça se fait assez vite. On le comprend et on le maîtrise.
BSP MIC 1 02:
Ce qui est intéressant dans ton propos, c'est que déjà, forcément, il y a le fait qu'une techno n'est pas bonne ou mauvaise en soi. C'est juste qu'il y a une question de contexte dans laquelle elle s'applique ou pas. Mais ce que je trouve aussi intéressant c'est que Cube est parfois présenté comme étant, une capacité de simplifier cette notion d'avoir du coup tous tes services qui sont conteneurisés, qui se répliquent facilement que tu peux du coup clusteriser enfin tu vois c'est toute une mécanique d'infra qui avant était très complexe à faire, alors je dis pas que Cube est simple, on sait que c'est une techno qui est quand même assez lourde, mais qui avait quand même vocation à simplifier, tout un ensemble d'organisations qui étaient un peu plus compliquées à faire avant. Mais du coup, toi, tu te dis que tu peux quand même simplifier sans passer par un outil comme Cube.
BSP MIC 2 02:
Ah oui, oui. Bah clairement.
BSP MIC 1 02:
Tu passes par un équivalent ou même pas ?
BSP MIC 2 02:
Non, enfin, on n'a même pas un équivalent. On avait fait un peu de Nomad à l'époque, du Hachicorp Nomad, qui était vraiment plus simple qu'un Kubernetes. On avait testé aussi Kamal, qui a été développé par DHH, donc le mec qui est derrière Ruby on Rails, ceux qui ont fait Basecamp, je ne sais pas si tu as entendu. Eux ont fait un gros move il y a peut-être deux ans de ça où ils ont dit on quitte le cloud complètement. même un peu plus que ça. Et en fait, ils se sont rendus compte qu'en fait, c'était très rentable de quitter le cloud, de quitter Cube et de ne pas avoir du Cube. Parce qu'ils n'en avaient pas le besoin. Mais il y a d'autres boîtes, par exemple, qui en ont besoin. Shopify, par exemple, sans Cube, ils ne peuvent pas survivre parce que leur infrastructure est tellement gigantesque et puissante que, bah oui. Mais en fait, pour moi, le niveau à partir duquel tu as besoin de Cube est beaucoup trop bas. C'est-à-dire qu'en fait, il faut bien comprendre que Cube est hyper intéressant, comme tu as dit, sur la définition S-Code et tout ça. Mais en fait, il faut comprendre qu'il faut le déployer, il faut le maintenir. Et ça, c'est beaucoup de choses que les gens oublient aussi. Ils prennent du Cube Managed. Moi, je ne peux pas prendre du cube managé. Je dois manager mon propre cube. Et là, ça change énormément de choses. Parce qu'en fait, il faut bien se rendre compte que les cubes qui sont hébergés, typiquement sur AWS ou Azure, ce n'est pas les cubes publics. Ils ont recodé des choses, ils ont amélioré des choses, ils ont changé d'autres outils. Et donc, en fait, ils n'ont souvent pas backporté ces problèmes-là. Quand tu vois, par exemple, Carpenter, qui marche très bien sur AWS et qui ne marche pas du tout sur d'autres cloud providers. Donc, tu as quand même... Kubernetes a permis de standardiser beaucoup de choses, mais il ne faut pas se dire que je prends mon cluster cube je le mets ailleurs, ça marche et donc nous on a ce problème là.
BSP MIC 1 02:
Quand tu dis que la barrière elle est le seuil à partir duquel c'est nécessaire que ce seuil là est trop bas tu parles d'une réalité technique ou d'une perception des gens qui se disent quand je suis à tel niveau il faut que je passe sur Kubernetes Tu sais c'est le.
BSP MIC 2 02:
Je pense que c'est la perception des gens en fait c'est alors dans une de mes activités aussi j'aide beaucoup des fonds d'investissement basés au Moyen-Orient et évoluer des startups Et je rencontre également des startups en croissance très intéressantes. Et par exemple, une fois, je me souviens qu'il y a un mec qui est venu me voir qui a dit « Ouais, voilà, on va tout bouger ». Alors, ils étaient chez DigitalOcean. Ils ont dit « Non, on va tout bouger chez la WS parce que notre base de données devient trop grande. DigitalOcean, ils n'y arrivent pas. » Je lui ai dit « Ah bon, elle fait quelle taille, TADB ? » « Elle fait 50 gigas. », Qui n'est pas assez grand que ça. Donc tu vois, une base de post-grès peut prendre 80 terrasse sans aucun problème. Donc à un moment, il faut bien se rendre compte que les gens ont une perception très biaisée. Et c'est ce que je dis à chaque fois, c'est que vous avez le problème de votre débit, regardez les index déjà. Parce que beaucoup n'ont même pas d'index. Et en fait, c'est ça aussi. C'est le côté vicieux du cloud, je trouve, c'est qu'en fait, ça ne te force pas à aller travailler là-dessus. Parce qu'en fait, tu vas juste dire « je vais rajouter de la RAM ». Tout passe en RAM et puis après, c'est rapide à nouveau. Mais tu vois, donc tu as un peu cette perte aussi de connaissance que je trouve très dommageable. Et ça fait que t'es beaucoup trop cher aussi. J'ai vu beaucoup de gens qui claquaient 20, 30 000, 40 000 dollars par mois sur Azure, alors que s'ils avaient été hébergés sur une solution on va dire plus réaliste et qu'ils avaient fait des choix techniques un peu différents aussi, ils devraient même pas payer un dixième de ça.
BSP MIC 1 02:
Je te rejoins complètement en fait sur le fait que, De manière assez globale, les gens, effectivement, déjà ont tendance à surévaluer l'importance de ce qu'ils font, de leur métier au quotidien, en disant qu'en fait, on a énormément de données, alors qu'en fait, il y a des gens qui ont... On est sur un ordre de grandeur de 10 puissance 4 ou 10 puissance 5 de plus. Et qu'en fait, les technologies qu'ils ont peuvent très bien fonctionner. Mais tu vois ce que tu évoques sur le fait que ça coûte plus cher ? Je pense qu'au final c'est pas forcément que ça coûte plus cher mais c'est que c'est plus facile de dépenser de l'argent en augmentant ton, hébergement AWS et autres plutôt que de dépenser plus d'argent ton équipe de dev, qui doit du coup aller creuser des sujets techniques différents qui doit du coup monter en compétenance sur d'autres sujets ou peut-être même faire grandir l'équipe technique et te dire en fait que ça, ça va te coûter plus cher, tu vas passer plus de temps à développer des choses structurantes et moins de la feature, et du coup tu préfères te dire bon en fait je mets de l'argent sur l'hébergement c'est.
BSP MIC 2 02:
Comme ça.
BSP MIC 1 02:
Effectivement je mets tout en RAM ça coûte plus cher mais au final je retrouve mes performances de rapidité quoi.
BSP MIC 2 02:
Ouais jusqu'à ce que ça te coûte vraiment trop cher et que tu craches et qu'en fait ta facture de cloud devient ton plus gros problème et là en fait c'est trop tard parce que quand tu as accumulé cette dette technique parce que c'est littéralement c'est de la dette technique quand tu l'as accumulé sur 3, 4, 5 ans, bah pour aller le patcher alors je sais qu'il y a fait des miracles maintenant pour tout réécrire à la volée, mais ça va être compliqué quand même parce que généralement aussi quand t'as pas fait ça t'as pas écrit de test enfin ça vient avec tout un process de start-up et donc là c'est trop tard en fait c'est-à-dire que tu as intérêt à avoir les reins très solides ou à faire une très grosse levée de fonds pour tout réécrire, et encore une fois je trouve ça dommage en fait d'avoir cette vision, un peu du shine de la tech on va faire un truc, on va le construire on s'en fout que ce soit de la bonne qualité, on le jette après, on le réécrit on le voit sur beaucoup de start-up qui font ça, j'ai écrit une première version je jette tout, je recommence à la levée de fond de la suivante je jette tout et en fait c'est pas ça qu'il faut faire la tech c'est pas ça la tech c'est de l'industrie, il y en a qui disent que c'est de l'artisanat, c'est faux c'est de l'industrie, il faut améliorer en permanence et pour moi les meilleurs là-dedans, le meilleur exemple qu'on a c'est Toyota qui font du Kaizen, donc c'est vraiment de l'amélioration permanente. En fait, quand tu commences à avoir ce processus en place, t'as des bien meilleurs résultats. Et alors, t'as dit un truc aussi, t'as un autre problème aussi par rapport au cloud, c'est que il y a une vision de managériale qui est mauvaise aussi. Je vais t'expliquer ce que j'ai dans la tête à ce moment-là. Quand tu dis, je vais mettre un budget de cloud de, je sais pas, 250 000 euros par an, les gens diront, ok, c'est le prix. Par contre, quand tu dis, je vais mettre 150 000 de cloud et 100 000 de dev, ils ont beaucoup plus peur parce que c'est de l'humain. Donc ça, c'est le premier problème. Et le deuxième problème, c'est ce que j'appelle les CV-driven technologies. En gros, pourquoi des mecs vont mettre cube alors qu'ils n'ont pas de trafic ? Parce qu'en fait, il sait qu'il pourra jumper au job suivant après et qu'il aura un meilleur salaire. Il faut relativiser tout ça au niveau de la tech. Il faudrait un peu redonner à la tech cette vision business. Et ça, c'est un truc que j'ai beaucoup appris à Dubaï parce que... Dubaï a plein de défauts, plein de qualités, mais Mais une des qualités, c'est vraiment ce marché, c'est son plus grand défaut, ce marché débridé, le business avant tout. Et bien en fait, quand tu comprends que ta feature là, d'accord, elle va t'apporter de temps, mais elle va te faire perdre de temps. Parce qu'elle va te coûter tant en cloud et qu'en fait, pour la rentabiliser, il faudra que tu aies un million d'utilisateurs actifs, qui est plus que le nombre d'utilisateurs actifs du pays. Bah, tu te rends bien compte que tu as un problème. Et en fait, on perd énormément. On essaie de s'enfermer, nous, je pense qu'en tant que tech, et j'en fais partie, vraiment, je ne juge pas là. On s'enferme dans notre bulle tech, on va essayer de faire la meilleure plateforme sans se rendre compte de l'impact que ça aura sur le business. C'est pour ça que tous les départements tech et marketing se foutent sur la gueule, de manière générale. Parce que tu en as certains qui sont travaillés par le business, d'autres qui sont travaillés par la tech. et qu'en fait, on devrait avoir un objectif commun.
BSP MIC 1 02:
Ça, là-dessus, je suis complètement aligné. Moi, ce que je défends souvent, c'est qu'effectivement, il faudrait que les devs aient une meilleure connaissance, de leurs utilisateurs, de leurs clients, parce que c'est primordial, en fait, de savoir quels sont les problèmes qu'on veut résoudre et à qui on apporte quelque chose. Et qu'effectivement, faire de la tech pour faire de la tech, ce n'est pas nécessaire. Ce que je trouve intéressant, au final aussi, dans ce que tu évoques, c'est que ce contexte très limité que vous avez, donc contraint, ou résilient, en fait, t'obliges un ensemble d'innovations et t'obliges un niveau de compréhension des sujets qui est hyper élevé. Et effectivement, ça peut se perdre quand t'es dans des contextes un peu trop privilégiés où, en fait, les choses sont facilitées par l'accès à des moyens.
BSP MIC 2 02:
— Ben oui, clairement. Tiens, le meilleur exemple, c'est les lots de balancers. Faire un lot de balancers, c'est compliqué. On a parlé de CleverCloud tout à l'heure, ils auraient écrit leur en Rust. Bon, j'aime pas Rust, mais bon, voilà. Mais en fait, quand tu vois un load balancer sur AWS, bon, c'est deux clics et c'est fait. Quand toi, tu dois faire ton load balancer et que tu commences à prendre 5, 10 000, 15 000 requêtes secondes, tu commences à avoir des problèmes de log, tu commences à avoir des problèmes de latence, tu commences à avoir des problèmes de mémoire, tu as énormément de problèmes comme ça. Et donc, ça te... Fais, par exemple, changer la manière dont tu vas déployer. Je vais te donner un exemple concret. Quand tu fais de la SPI, tu as une single page application, tu as ton domaine principal, disons que c'est ifttd.io, c'est ça ? Et puis après, tu vas avoir api.iftd.io. Donc, tu as ton application et ton domaine sont séparés. Qu'est-ce qui se passe ? Tu as un problème de Corse. Alors, pas celui du sud de la France, mais les CORS. Bon. Donc, qu'est-ce qui se passe ? À chaque fois que tu vas faire une requête, tu vas être obligé de faire, alors pas à chaque fois mais tu vas être obligé de faire un call options qui te bouffe rien ça ne te bouffe rien tu envoies un message options et il te renvoie les leaders qui sont autorisés les domaines autorisés etc, on est d'accord que sur du cloud tu t'en fiches ça va peut-être augmenter un petit peu ta facture AWS mais ça va être négligeable c'est.
BSP MIC 1 02:
Un appel minime qui passe en quelques microsecondes et puis c'est marre.
BSP MIC 2 02:
Par contre quand tu commences à dire attends ça fait 20% de mes appels d'API, et que moi j'ai 20% de mon trafic c'est juste ça et je te parle même pas en trafic en bande passante mais en nombre de requêtes, ça devient vachement plus intéressant de se dire ah ben non je vais faire mon domaine slash API parce que là j'ai plus de course et donc tu vois il y a énormément de choses comme ça où tu vas changer la manière dont tu construis et tu vas, je dirais un peu rationaliser d'une certaine manière.
BSP MIC 1 02:
Hyper intéressant. Est-ce que tu penses... Parce qu'un sujet, moi, j'ai évoqué plusieurs fois sur ce podcast. Moi, j'ai commencé à coder au siècle dernier. Moi aussi, oui. Et à l'époque, quand tu voulais faire un site web, en fait, tu avais très peu de langage à maîtriser. Tu pouvais juste avoir... Tu avais ta machine, ton ordinateur qui était installé dans ton salon, qui pouvait faire office de serveur. tu avais très peu de techno. Tu pouvais très vite mettre quelque chose à disposition sur Internet. Aujourd'hui, les techno se sont démultipliés, les techno se sont énormément complexifiés. Au siècle dernier, développeur front, ce n'était pas forcément un vrai métier parce que c'était juste de l'intégration HTML. Aujourd'hui, un développeur réacte, c'est une vraie expertise, c'est un vrai métier. Il y a une vraie complexité dans la création d'applications purement front. Il y a une vraie complexification des choses et je trouve en fait que ça pose question sur sur est ce qu'on peut encore demander sereinement à un être humain de maîtriser tous ces sujets là tu me parles de beaucoup de sujets techniques de se dire effectivement de se dire est ce que pour éviter les problèmes effectivement de corse je choisis de faire un sous domaine faire plutôt un chemin, différent mais tu vois tu nous évoquais les sujets de cybersécurité des sujets de performance d'accès mémoire de « je mets tout en RAM ou pas ». Je ne sais pas si aujourd'hui, un seul être humain est vraiment capable de maîtriser tous ces problèmes-là et se pose aussi la question de, est-ce que c'est vraiment nécessaire de maîtriser tous ces sujets-là ? Pour résumer la question, parce qu'on a vu ce débat aussi il y a longtemps sur un autre épisode, où il y avait mon invité qui disait, c'est dommage, il y a de moins en moins de développeurs et développeuses qui connaissent la différence entre TCP et UDP. Et donc oui ça avait généré tout un débat au sein de la communauté qui disait mais en fait moi je suis développeur React qu'est-ce que j'en ai à foutre de la différence entre TCP et UDP, tu vois ce que je veux dire est-ce que tous ces sujets tech qu'on évoque sur ce podcast que ce soit d'épisodes ou sur d'autres est-ce que c'est vraiment nécessaire tu penses pour les gens de notre industrie de maîtriser tout ça ?
BSP MIC 2 02:
De maîtriser non moi comme je t'ai dit je suis 6 admin le front non mais je pense que c'est bien avoir une certaine culture générale même des domaines où tu ne maîtrises pas complètement c'est pour ça que tu as des podcasts comme le tiers d'ailleurs on apprend des choses, j'ai appris des choses sur les recommandations je ne vais pas refaire de la recommandation demain on reste d'accord là-dessus, donc il faut quand même qu'on ait une culture générale très importante, c'est de l'ingénierie à la fin il faut qu'on connaisse tout ça et qu'on soit capable de détecter les erreurs plus tôt c'est pas. Je pense que l'idée c'est pas de se dire je vais tout connaître c'est « Je connais un minimum pour éviter de faire une grosse connerie ». Et en fait, si à ce moment-là, tu dis « Ah, attends, là, j'ai plein de problèmes, tu appelles un copain, un collègue, n'importe quoi, j'avais pensé à faire ça, t'en dis quoi ? Ah non, t'as fait une connerie, et puis on passe à l'étape suivante. » Et c'est ça, en fait, c'est un truc que je ne comprends pas, et tu vas rebondir sur ton sujet. On est en train de dire que les full stack n'existent plus, je suis d'accord avec ça. On a parlé du DevOps aussi, et en fait, on a dit « Attends, DevOps, l'idée, c'était comme de dire, on met les 6 admins et les devs qui se détestent, on les met ensemble pour qu'ils communiquent et qu'on avance tous ensemble. » Et là, on est en train de re-siloter l'intégralité de l'industrie, alors que pour moi, c'est l'opposé. Il faudrait que tout le monde soit à nouveau ensemble et qu'on arrête. Et pour moi, un dev front, moi, j'ai des devs front dans mon équipe. Je suis incapable de faire ce qu'ils font. Par contre, je suis capable de détecter des erreurs qu'ils vont faire, typiquement sur de l'upload de fichiers. Tu vois, des trucs un peu système où là, je vais faire... Ah, attends, là, l'upload... Non, non, non, ça, c'est pas possible, quoi. Tu vois ? Je vais te donner un exemple très spécifique là-dessus. Quand tu fais du S3, ce qu'on appelle du S3 de nos jours. API S3, tu as un truc qui s'appelle les pré-sign URL. En gros, tu dis à S3, génère-moi un lien pour que quelqu'un puisse faire quelque chose sur un fichier. Voici le chemin, voici le temps de validité. Et c'est très bien quand tu récupères de l'information. Parce que là, c'est-à-dire que moi, je te dis, à place de te laisser l'accès direct à ton fichier, par exemple, une image, c'est derrière une protection qui va expirer dans 10 secondes. Si tu as besoin de la recommencer, tu peux aller la recharger. Il n'y a pas de problème et tu dois faire un code API d'abord. Très bien. Par contre, quand tu veux uploader des fichiers, qu'est-ce qui va se passer ? Si tu fais un pressign URL, en fait, la vérification de ton fichier arrive qu'une fois que tu as fini l'upload. Et comme tu le sais sur AWS, tu payes tout. Tu payes le trafic entrant, le trafic sortant et le stockage. Moi, maintenant, tu me donnes un pressign URL. Et tu me dis. Tu as droit d'uploader ton image de profil. Et moi, je t'envoie un fichier de 150 Go. Ça va mettre longtemps, mais à la fin ça va marcher, j'ai l'uploadé et toi tu as une vérification derrière qui va dire ah bah non, l'image va être grosse, c'est même pas une image Loïc tu m'emmerdes, voilà, dégage mais entre temps j'ai fait des dégâts, alors que par exemple une post-policy qui est la bonne manière de le faire pour l'upload de fichiers tu vas mettre le type de fichier, la taille et tu as énormément plus de contraintes donc tu vois ça, je ne m'attends pas à ce qu'un dev front-end sache ça, mais ce que je m'attends c'est qu'en fait on en discute, qu'on puisse échanger et que là je lui dise « Ah non mais attends, n'utilise pas un pressign pour envoyer du fichier, utilise un post-policy.
BSP MIC 1 02:
» Donc c'est la complémentarité des compétences, c'est le travail collaboratif ?
BSP MIC 2 02:
Et pour moi, c'est ça. Et je ne comprends pas qu'on ait encore des guerres de chapelle qui ne font aucun sens. J'étais encore... Là, je suis plutôt basé à Nancy, en France. Il y a des guerres de chapelle sur les langages de programmation. Ah non, mais il fait du PHP, je ne veux pas lui parler. Non, mais attends, enfin, maman, il faut arrêter. On est une grande famille, il faut qu'on aille de l'avant tous ensemble. En plus, avec l'IA qui va nous faire vraiment mal, il faut être clair là-dessus, notre métier va évoluer. Autant qu'on y aille tous ensemble et qu'on fasse avancer le schmilblick, quoi. C'est un peu...
BSP MIC 1 02:
— Pleinement aligné. Le dernier sujet aussi qu'on pourrait évoquer, c'est bien évidemment des sujets de souveraineté. Parce qu'au final, tu es en plein dedans. C'est-à-dire que tu fournis un service qui permet d'avoir un clôt de souverain pour les gens qui sont basés à Dubaï et ce genre de choses. C'est quoi, toi, ta perception de la nécessité de souveraineté aujourd'hui, en 2026 ?
BSP MIC 2 02:
C'est qu'elle devient de plus en plus importante, surtout avec l'IA. Je vais t'expliquer pourquoi. Je bosse avec des boîtes, par exemple, qui ont Pipedrive, comme CRM. C'est bien, Pipedrive, ça marche bien, ce design, ça va, voilà. Par contre, quand tu veux l'intégrer avec des outils d'IA, ils te limitent au niveau de l'API. Et si tu veux plus d'API call, ou tu payes, ou tu attends. Et en fait, je pense qu'on est à peu près de la même génération, il y a 10 ans, tu te souviens, on nous disait, la data, c'est le nouvel or. Même plus que 10 ans maintenant mais bon, passons, ça nous vieillit, et bien en fait c'est ça la souveraineté c'est être capable d'aller chercher sa data de l'exploiter comme on veut, quand on veut je ne comprends pas maintenant qu'il y a encore des gens qui utilisent des SaaS où tu n'as pas un accès à la DB derrière, et c'est pour moi le plus gros problème qu'on a actuellement c'est que quand tu vas avoir des trucs de type openclow ou ce genre d'outils qui vont avoir besoin d'agréger normalement data d'aller en chercher, d'aller en récupérer, d'aller en renvoyer si tu commences à être limité au niveau de tes cols API ou de l'accès à ta donnée, automatiquement tu seras derrière et c'est pour ça que le self-hosted est en train aussi je pense de décoller OpenClo l'a montré récemment très fortement mais quand tu prends par exemple MiCode. Underscore qui t'explique qu'ils sont passés sur un CRM qui est open source parce qu'en fait ils pouvaient les taper dedans automatiquement et en fait tout ça, cette souveraineté ne va pas être jusqu'à maintenant la souveraineté, on en parlait avant, c'est quelque chose qui était pour les fous furieux non on va mettre du linux parce que windows c'est mal machin tout ça là maintenant c'est devenu une nécessité parce que fait tu vas avoir besoin de cette souveraineté de la data pour aller de l'avant avec de lire et c'est vraiment mon opinion forte j'aurais peut-être tort peut-être que dans deux ans tu me réinviteras et tu me diras bah lui que tu avais tort mais c'est vraiment mon opinion parce que c'est ce qui va te propulser de l'avant, Et ça va être la même chose sur tout, en fait. Et en plus, t'as le risque quand même de se dire, qu'est-ce qui se passe si demain, Trump, il dit, on coupe AWS en Europe. On l'a vu avec le juge de la Cour pénale internationale, qui a plus le droit à des cartes bancaires, à des téléphones. Qu'est-ce qui se passe si lui, demain, il attaque le Greenland et que nous, on envoie de l'armée là-bas et qu'ils disent, plus AWS, plus Android, plus iPhone. Qu'est-ce qu'on fait ? Et en fait, la question, c'est plus. Est-ce que la souveraineté, c'est important, c'est déjà une nécessité. Et c'est là, en fait, où on va, je pense, le plus progresser aussi, en fait. Limite, il nous faudrait ça pour qu'on avance. C'est ce qui s'est passé avec la Chine. La Chine a dit un jour, on stop Instagram, on stop WhatsApp, on stop machin. Ils ont tout refait en interne, et maintenant, ça marche bien. La Russie a un peu fait ça aussi. Et je pense qu'il ne faut pas qu'on soit aussi extrême non plus. On est quand même des Européens, on est plus, je ne vais pas dire le mot, mais voilà, plus calme, on va dire, mais ça devait de nécessiter qu'on le fasse. Le fait qu'on ait, par exemple, les emails, on en parlait aussi avec Office 365 ou Gmail, enfin la Google Suite, on donne l'intégralité de nos data d'entreprise à des tierces parties. Et ça, pour moi, c'est hyper grave. J'en fais partie, d'ailleurs, nous, on est en train d'essayer d'en sortir, mais c'est tellement sticky. Comme solution, que nous, en fait, le plus dur, c'est pas de sortir des mails, c'est de sortir du drive. Et en fait, on est en train de se battre là-dessus parce qu'on stocke énormément de choses et il faut que ce soit disponible tout le temps. Donc t'as énormément de problèmes comme ça. On est en train de shifter pas mal de choses avec du self-assist, mais ça devient une nécessité. Il faut que ça le devienne.
BSP MIC 1 02:
— Ce qui est hyper intéressant dans ton explication, c'est que tu présentes bien, la souveraineté comme étant pas juste le sujet de se dire il faut que je sois hébergé à des endroits qui sont de mon pays pour éviter des situations géopolitiques compliquées, je trouvais ça hyper intéressant ce que tu disais au début, de dire en fait, il faut que tu aies un accès à ta donnée qui soit illimité et qu'effectivement, quand tu utilises un cloud code, un cloud ou je ne sais quoi et qu'en fait tu as un nombre d'appels API sur ta propre information qui est limité à x appels toutes les 15 minutes ou x appels par jour ou je ne sais quoi, c'est effectivement un vrai problème c'est que tu te retrouves obligé d'attendre parfois ou de dépenser plus donc t'as une dépendance effectivement, et qu'au final que cette dépendance elle soit auprès d'un acteur de ton pays ou pas ça reste problématique en fait si t'as pas accès à ton information quand t'en as besoin c'est problématique quoi.
BSP MIC 2 02:
En fait c'est même pas une question de géopolitique c'est juste est-ce que vous pouvez utiliser l'IA proprement dans votre entreprise et c'est tout et c'est la même chose pour l'exécution de l'IA, on a... Je ne sais pas où tu vas être dans la conversation, mais par exemple, nous, on fait beaucoup aussi d'IA on-prem, avec des serveurs NVIDIA, des cartes NVIDIA, ce genre de choses. Je ne comprends pas le retard qu'on a en France là-dessus. Quand tu prends, par exemple, un OpenAI, même un Mistral, d'ailleurs, je les adore, c'est des Français, c'est cool, mais à un moment, il faut vraiment aussi qu'on pense à se dire, on envoie quand même l'intégralité de notre data autre part. Et pour moi, tu ne peux pas faire ça. Moi, je ne suis pas prêt à faire ça. Je pense que personne ne devrait l'être.
BSP MIC 1 02:
Mais tu vois, le niveau de complexité, en fait, c'est-à-dire que tout le monde ne peut pas avoir une IA en self-hosted pour pouvoir accéder à son information en permanence. Il y a quand même un coût, il y a une complexité, mais je pense surtout une complexité. C'est-à-dire qu'on est de plus en plus sur des technos qui sont quand même hyper complexes. On ne parle pas forcément dans la communication de la Lune, Mais bon, c'est quand même pas accessible à tout le monde.
BSP MIC 2 02:
Ah mais je suis d'accord. Je ne te dis pas de le faire demain. Ce n'est pas ce que je te dis. Je dis ce qui est vrai, c'est un peu l'anticiper pour se dire que dans 3 à 5 ans, quand en fait le saut technologique va être tellement gros qu'on a des cartes qui vont arriver d'inférences, qui vont être françaises et qu'on va avoir des choses où on va pouvoir être on-prem, on pourra aller de l'avant. C'est là où je pense qu'il y a des pays qui ont une bien meilleure vision. Je vais reparler des Émirats que je connais bien. Ils ont un ministère de l'intelligence artificielle, un ministère de plein exercice. Le mec a fait de la recherche en IA le chef, et en fait ils ont cette vision de l'IA où ils vont la pousser à travers le gouvernement en balançant la souveraineté l'exécution, et en fait ça fait que, ils savent, ça sera pas demain ils le savent, mais ils bossent dessus ils disent en 2050 on sera autonome en 2050 on aura nos propres puces ils bossent sur des puces risque 5 en interne, pour ne pas être dépendants d'un italien d'AMD, et en fait c'est tout ça qui compte, c'est pas est-ce que tu fais un effort maintenant ou même à 5 ans c'est à 10 ans, 30 ans, 50 ans, C'est au moment où on va avoir... Au moment où on ne pourra plus utiliser de CPU Intel ou AMD, parce que les Américains ont mis un veto dessus ou un embargo, qu'est-ce qu'on fait ? Il nous reste ARM. D'accord. Mais ça va être un peu limité, quoi.
BSP MIC 1 02:
— Après, on a aussi la chance en Europe d'avoir... J'ai oublié le nom... Mais il y a cette boîte formidable qui construit les machines qui construisent les processeurs.
BSP MIC 2 02:
Oui. Les néerlandais, j'ai oublié le nom. Je ne sais plus le nom.
BSP MIC 1 02:
Je n'ai oublié plus le nom. Mais ça, c'est une merveille technologique. Donc en ce moment, on pourrait aussi répliquer en leur empêchant d'avoir accès aux machines qui permettent de créer les processeurs. Mais bon, après, on est sur une guerre géopolitique. De toute façon, c'est un autre débat. Passionnant. Merci beaucoup, Loïc, pour tout ça. J'aurais deux dernières questions pour toi qui sont les questions rituelles de ce podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditrices.
BSP MIC 2 02:
J'en ai plusieurs en fait alors déjà un parce que je suis français, j'aime soutenir la France un jeu vidéo pour ceux qui ne l'ont pas encore joué c'est Claire Obscur, Expedition 33, c'est pour moi la preuve qu'en France on est capable de faire des choses bien, j'en ai marre vraiment marre qu'on dise qu'à chaque fois en France c'est nul et qu'en fait les Américains font mieux, c'est pas vrai on a des très bons cerveaux Dans.
BSP MIC 1 02:
Le monde du jeu vidéo, pour le coup, les Français sont reconnus comme étant...
BSP MIC 2 02:
Enfin, Ubisoft est un peu en train de se casser la gueule, mais bon, ça c'est un autre débat. Mais dans l'idée, si on a réussi à le faire en jeu vidéo, on arrive à le faire ailleurs. On a quand même Mistral qui marche bien. On a la nouvelle start-up de Yann Lequin aussi qui arrive. On a des gens bien. On a des produits intéressants. Il faut soutenir l'industrie française. Il faut acheter français. Vous lancez une start-up, très bien. Arrêtez de prendre G Suite. Passez sur autre chose. Passez sur Proton, c'est des Suisses. Très bien. Passez sur Meilo, c'est des Français. c'est passer sur n'importe quoi. Arrêter de toujours aller vers la solution de facilité que tout le monde connaît. Essayer aussi de soutenir parce qu'à la fin, on en aura besoin à un moment. Et au moment où on en aura besoin, on regrettera de ne pas y avoir été. Ça, alors, c'est un exemple, entre autres. Et après, sur des ressources, j'en ai tellement, en fait. Alors, je vais en recommander un papier. Alors, moi, je lis beaucoup, beaucoup de thèses et de choses comme ça. Je trouve que c'est hyper intéressant. Et il y en a une qui est vraiment euh... Impeccable mais qui demande beaucoup de concentration, c'est la thèse de Joe Armstrong qui est un des créateurs du langage R-langue, Alors, je ne sais pas si tu connais Erlangue comme langage.
BSP MIC 1 02:
On a fait un épisode sur Erlangue, oui.
BSP MIC 2 02:
Je ne me souviens plus. Peut-être que je ne l'ai pas écouté, mais voilà. Et en gros, la thèse est absolument fabuleuse. Elle t'explique tout un tas de concepts. On a vu il y a plus de 30 ans maintenant la thèse. Sur des choses que Kubernetes, on en parlait, est en train d'essayer d'implémenter maintenant. Et c'est hyper intéressant. Et je pense qu'on sous-estime vraiment encore dans la tech de nos jours ce genre de rapport, ce genre de thèse et aller lire des bouquins. Il faut qu'on revienne à aller voir des tutos Youtube c'est cool, aller écouter des podcasts, c'est cool ça te donne des idées, mais il faut aussi qu'on n'oublie pas qu'on a un métier d'ingénierie il faut aller chercher des trucs un peu plus poussés ok.
BSP MIC 1 02:
Canon on va mettre rapidement les liens en description et je vous mettrai aussi le lien vers l'épisode qu'on a fait sur Airlang il y a un petit moment déjà, je crois que c'était il y a bien 3-4 ans un épisode hyper intéressant on va parler du coup notamment de Whatsapp ah bah oui.
BSP MIC 2 02:
Parce que c'est du jabber.
BSP MIC 1 02:
Oui, exactement Pour terminer, la dernière question qui est la plus importante de ce podcast, Loïc, tu es plutôt espace ou tabulation ?
BSP MIC 2 02:
Je suis un mec efficace, donc tabulation quoi Très bien.
BSP MIC 1 02:
Merci beaucoup Loïc.
BSP MIC 2 02:
Pas de soucis.
BSP MIC 1 02:
Merci à tous d'avoir suivi cet épisode très riche, on a parlé d'énormément de sujets, j'aime beaucoup le message de fin, c'est qu'on est un métier d'ingénierie donc il faut effectivement développer ce savoir et cette culture, autour de beaucoup d'aspects Il y a aussi, effectivement, de ce côté, on a un métier qui est très collaboratif, malgré l'image que certains peuvent en avoir. Donc effectivement, il faut s'entourer de personnes qui ont des expertises différentes pour éviter d'avoir des angles morts sur différents sujets. On ne peut pas tout savoir, mais on a suffisamment de gens autour de nous pour réussir à tout couvrir. Je vous remercie comme toujours de partager ce podcast autour de vous n'hésitez pas à aller checker, je vous le redis encore une fois lemcp.fttd.io si vous voulez avoir tout ce savoir-là directement dans votre IDE je vous remercie aussi de soutenir ce podcast, je vous souhaite une très bonne fin de semaine je vous dis à la semaine prochaine et d'ici là, codez bien.
