Archives de catégorie : Informatique

Informatique

Januscape : comment OVHcloud a patché en urgence

Laisser un commentaire

Januscape OVHcloud a mis en lumière un scénario que tout hébergeur redoute : une faille exploitable pouvant faire planter l’hôte physique. Quand l’attaque vise l’infrastructure elle-même, la question n’est plus “si” on corrige, mais “comment” on corrige vite, à grande échelle, sans multiplier les dégâts. OVHcloud a publié un retour d’expérience détaillé : chronologie, arbitrages et choix opérationnels, jusqu’aux ratés.

Le contexte : une faille qui touche l’hôte physique

La faille Januscape a été révélée comme un problème où une machine virtuelle louée peut provoquer le plantage du serveur physique qui l’héberge. Pour un acteur disposant de dizaines de milliers d’hôtes et d’environ un million de machines virtuelles, cela change la nature de l’urgence : il ne s’agit pas seulement de corriger des services, mais de sécuriser la plateforme d’exécution elle-même.

Dans son billet, OVHcloud explique avoir dû répondre à une double contrainte : agir rapidement, tout en tenant compte du fait que l’impact d’un correctif peut se traduire par des redémarrages et des effets de bord sur certains environnements.

Carte du monde illustrant le déploiement par relais horaire
Carte du monde illustrant le déploiement par relais horaire

11 jours pour patcher : la chronologie d’une réponse

OVHcloud décrit une opération structurée en étapes très courtes, avec des validations internes et des décisions prises au fil de l’eau. L’alerte tombe le 7 juillet en début d’après-midi. Le correctif est adapté aux noyaux Debian maison dans la journée, puis validé en laboratoire le soir.

Le point clé : l’équipe teste le comportement de l’exploit dans un cadre interne, et constate un plantage d’un hôte non corrigé en quelques minutes. Cette validation sert de base au feu vert décisionnel.

Le “follow the sun” pour enchaîner les régions

Le déploiement démarre depuis Sydney, un choix présenté comme moins “exotique” qu’il n’y paraît : la région est petite et sa nuit locale correspond aux heures de travail des équipes européennes. Une fois la procédure validée en conditions réelles, OVHcloud enclenche une logique de relais : chaque région prend le relais sur sa matinée locale, en continu.

Des seuils d’arrêt pour éviter l’emballement

Pour piloter le rythme, l’entreprise encadre l’opération avec des seuils. Par exemple, si le nombre d’hôtes en panne simultanée dépasse un certain niveau dans les régions les plus denses (et un niveau différent ailleurs), la vague est suspendue le temps que les techniciens de datacenter interviennent.

Sur la première nuit, OVHcloud indique que 20 à 30 hôtes sur 6 000 ne sont pas revenus seuls, avec des causes évoquées comme des barrettes mémoire ou des problèmes de configuration.

Le choix le plus lourd : corriger puis redémarrer

OVHcloud explique qu’il existait plusieurs options sur la table : attendre un correctif “officiel” via des noyaux, passer par un correctif à chaud, ou encore migrer massivement les machines virtuelles. Toutes sont écartées au profit d’une approche jugée la plus radicale : corriger puis redémarrer l’intégralité des hôtes.

Cette stratégie repose sur une idée simple : si la faille peut conduire à des plantages, alors la correction doit atteindre le niveau le plus fondamental de l’infrastructure, même si cela implique un impact opérationnel.

Orchestration de correctifs et redémarrages sur des hôtes de datacenter
Orchestration de correctifs et redémarrages sur des hôtes de datacenter

“Patching unilatéral à impact contrôlé” : sans fenêtre de maintenance client

Le billet assume un point sensible : pas de fenêtre de maintenance négociée client par client. OVHcloud parle d’un patching unilatéral à impact contrôlé : les redémarrages sont appliqués sans accord individuel, et l’impact est considéré comme inévitable, à condition d’être maîtrisé.

Pour limiter la casse, l’entreprise met en place une logique d’orchestration basée sur un graphe de colocalisation. L’objectif est de ne pas redémarrer en même temps deux hôtes portant des instances d’un même projet client.

Anti-affinité “best effort” : pas de garantie absolue

OVHcloud revendique une anti-affinité en “best effort”, c’est-à-dire une approche qui réduit le risque sans pouvoir garantir un résultat parfait dans tous les cas. Concrètement, cela signifie que l’orchestration cherche à éviter les situations les plus dommageables, mais qu’elle ne peut pas éliminer toute possibilité de collision.

Les charges critiques : migration à chaud au cas par cas

Les charges les plus sensibles, notamment des machines virtuelles de bases de données managées, sont traitées autrement : OVHcloud indique avoir migré ces éléments à chaud, une par une. L’idée est de préserver la continuité là où elle est la plus difficile à obtenir via un simple redémarrage.

La communication : assumer, documenter… et gérer le silence initial

Dans son retour d’expérience, OVHcloud aborde aussi la dimension communication. L’entreprise explique avoir choisi de ne pas publier immédiatement une page d’état publique, afin de ne pas exposer certains détails susceptibles d’être utilisés.

Ce choix illustre un dilemme classique en cybersécurité : informer tôt peut aider les clients à se préparer, mais cela peut aussi fournir des repères à des acteurs malveillants. OVHcloud semble avoir privilégié la réduction du risque pendant la phase la plus critique.

Ce qu’on peut retenir : une méthode réplicable pour les crises de patch

Au-delà du cas Januscape, le retour d’expérience met en avant des principes opérationnels utiles quand une faille touche l’infrastructure :

  • Valider vite : adapter le correctif et tester l’impact en laboratoire avant d’industrialiser.
  • Choisir une stratégie “niveau infrastructure” quand la faille est structurelle (ici, redémarrer après correction).
  • Orchestrer le risque : anti-affinité et logique de colocalisation pour limiter les effets simultanés.
  • Rythmer avec des garde-fous : seuils d’arrêt et interventions datacenter planifiées.
  • Traiter les charges critiques différemment : migration à chaud quand c’est nécessaire.

Conclusion : la sécurité, c’est aussi de la décision sous contrainte

Januscape OVHcloud n’est pas seulement une histoire de correctif. C’est une histoire de décisions : quand corriger, comment redémarrer, comment limiter l’impact, et comment communiquer sans augmenter le risque. Le message implicite est clair : en cybersécurité, la vitesse compte, mais la méthode compte tout autant.

La prochaine question, pour les équipes techniques comme pour les clients, est simple : comment préparer à l’avance des plans de patch “à grande échelle” pour que l’urgence ne devienne pas une improvisation ?

Source : https://www.clubic.com/actualite-622141-januscape-ovhcloud-raconte-11-jours-de-crise-pour-patcher-son-parc-mondial.html

Informatique

Clés SSH : arrête de les générer n’importe comment

Laisser un commentaire

Quand on se lance dans le self-hosting, on finit toujours par taper la même commande : ssh-keygen, Entrée trois fois, et hop… ça marche. Sauf que tes clés SSH ne sont pas un détail : ce sont littéralement les clés d’accès à tes serveurs. Et si tu les fabriques ou les organises mal, tu passes très vite de « un fichier volé » à « un accès permanent à tout ton parc ».

Dans ce guide, je te donne la méthode que j’applique sur mon homelab : bon format, bonne commande, passphrase obligatoire, organisation par usages, et ssh-agent bien configuré. Pas de théorie inutile : juste des décisions concrètes qui réduisent le risque.

1) Le bon format en 2026 : Ed25519, point

Si tu ne dois retenir qu’une chose : génère tes clés en Ed25519. La commande minimale est :

ssh-keygen -t ed25519

Pourquoi je pousse Ed25519 ? Parce que c’est un choix moderne, efficace et robuste dans l’écosystème OpenSSH. Et surtout : c’est le format que tu veux standardiser dans ton homelab, pour éviter les exceptions et les “ça marche chez moi” qui finissent par coûter cher.

Ce que tu évites

  • DSA : obsolète, à oublier.
  • ECDSA : acceptable en théorie, mais je préfère éviter les compromis et rester sur Ed25519.
  • RSA : utile uniquement pour l’interop avec un vieux système. Sinon, tu perds du temps à gérer un héritage.
Commande ssh-keygen en Ed25519 avec indicateurs de sécurité
Commande ssh-keygen en Ed25519 avec indicateurs de sécurité

2) La commande idéale, décortiquée

Voici la ligne que j’utilise et que je te recommande d’adopter comme standard :

ssh-keygen -t ed25519 -a 100 -C "moi@mon-pc" -f ~/.ssh/id_ed25519_mon_pc

Chaque option a un rôle. Et c’est précisément là que beaucoup de gens “génèrent n’importe comment” : ils laissent des valeurs par défaut sans comprendre ce qu’elles protègent.

-t ed25519 : le type de clé

On l’a vu : c’est ton standard. Pas de débat.

-a 100 : le blindage du fichier au repos

Ta clé privée n’est pas stockée en clair si tu mets une passphrase. Elle est chiffrée, et -a règle le coût de dérivation de la clé de chiffrement (KDF). Plus tu augmentes ce coût, plus un attaquant qui vole le fichier doit “payer” du temps pour tester des passphrases.

En pratique, 100 est un bon compromis : tu ne le sens presque pas à l’usage (une fois au déverrouillage), mais tu rends les essais beaucoup plus coûteux pour un attaquant.

Point important : -a ne sert à rien si tu ne mets pas de passphrase. Donc on enchaîne.

-C : un commentaire utile

Le commentaire (moi@mon-pc) n’ajoute pas de sécurité cryptographique. Mais il te sauve la vie quand tu retrouves une clé dans un authorized_keys six mois plus tard : tu sais à quoi elle correspond.

-f : le nom explicite qui évite le chaos

Le chemin de sortie (~/.ssh/id_ed25519_mon_pc) n’est pas qu’un détail. C’est l’organisation qui te permet de savoir quelle clé est où, et de révoquer vite quand une machine change.

Ce que je ne fais jamais : -N

Je ne passe jamais la passphrase en argument avec -N. Elle finirait dans l’historique de ton shell ou dans des logs. Tu la tapes au prompt, c’est plus sûr.

3) Passphrase obligatoire (et comment ne pas la rendre pénible)

Une clé SSH sans passphrase, c’est une clé privée qui peut ouvrir tes serveurs et qui traîne sur ton disque. Si un jour ta machine est compromise, la “sécurité au repos” disparaît.

Ma règle : toujours une passphrase forte. Et ensuite, on gère le confort avec ssh-agent.

Une clé SSH ne s’expire pas : attention aux clés oubliées dans authorized_keys
Une clé SSH ne s’expire pas : attention aux clés oubliées dans authorized_keys

4) Le piège : une clé SSH n’expire jamais

Contrairement à un certificat TLS, une paire de clés SSH “classique” n’a pas de date de validité. Une fois que ta clé publique est dans authorized_keys, elle fonctionne indéfiniment jusqu’à ce que tu la retires.

Le vrai danger en homelab, ce n’est pas “la clé trop vieille”. C’est la clé oubliée : un ancien laptop revendu, une VM réinstallée, un téléphone perdu… et pourtant l’accès reste valide parce que personne n’a fait le ménage.

Deux solutions réalistes

  1. Rotation manuelle : tu régénères tes paires périodiquement (par exemple une fois par an) et tu remplaces les clés publiques sur tes serveurs.
  2. Certificats SSH : tu utilises une CA et des certificats avec une fenêtre de validité. Quand ça expire, le serveur refuse automatiquement.

Mon avis : pour un petit parc (un VPS + un NAS), monter une PKI complète peut être disproportionné. Mais dès que tu passes à plusieurs machines, l’approche certificats devient intéressante. Dans tous les cas, garde en tête une règle : audit régulier de qui a accès à quoi.

5) Combien de clés ? et combien de passphrases ?

On confond souvent deux décisions différentes : le nombre de clés et le nombre de passphrases. Elles ne répondent pas aux mêmes objectifs.

“Une clé par usage” ≠ “une clé par serveur”

Le bon découpage, ce n’est pas la destination (VPS, NAS, etc.). C’est le point de départ : quelle machine cliente et quel contexte.

Exemple de découpage sain :

PC       → id_ed25519_pc       (ouvre VPS, NAS, etc.)
Laptop   → id_ed25519_laptop   (ouvre VPS, NAS, etc.)
PC       → id_ed25519_github   (dédiée aux services tiers)

Pourquoi une clé dédiée pour GitHub / services tiers ? Parce que tu confies la clé publique à un tiers. Autant qu’elle ne soit pas réutilisée pour tes accès “maison”.

Une passphrase par machine (pas par clé)

La passphrase sert à protéger un fichier de clé privée volé. Si plusieurs clés vivent sur la même machine et partagent la même passphrase, un attaquant qui accède au disque pourra tenter cette passphrase pour toutes.

Mon conseil pragmatique : une passphrase forte et unique par machine cliente. Toutes les clés générées sur ce poste peuvent partager cette passphrase.

Deux exceptions où tu cloisonnes plus

  • Clé tierce (GitHub / services) : passphrase distincte si tu veux renforcer l’isolation.
  • Clé matérielle (ex. ed25519-sk) pour ton accès le plus sensible : la partie secrète ne peut pas être copiée depuis le disque. Là, la passphrase devient presque secondaire, parce que voler le fichier ne suffit plus.

6) ssh-agent : le confort sans sacrifier la sécurité

“Taper une passphrase à chaque connexion, c’est infernal.” Oui. Mais justement : on ne le fait pas. ssh-agent garde tes clés déchiffrées en mémoire le temps de la session.

Le but : tu tapes la passphrase une fois, puis tu enchaînes tes connexions sans friction.

ssh-agent garde les clés en mémoire pour éviter de retaper la passphrase
ssh-agent garde les clés en mémoire pour éviter de retaper la passphrase

Le réflexe qui change tout : AddKeysToAgent yes

Dans ~/.ssh/config, je mets :

Host *
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519_mon_pc

Résultat : à la première utilisation, SSH charge la clé dans l’agent. Ensuite, tu ne retapes pas la passphrase tant que l’agent vit.

Évite les mauvaises surprises : IdentitiesOnly yes

Quand tu as plusieurs clés, SSH peut essayer “trop de choses” et provoquer des refus côté serveur. Pour forcer la clé attendue, je recommande :

Host mon_serveur
  HostName ton.ip.ou.domaine
  User user_distant
  IdentityFile ~/.ssh/id_ed25519_mon_pc
  IdentitiesOnly yes

7) Bien gérer ssh-agent selon ton OS

Le problème n’est pas ssh-agent. Le problème, c’est le démarrage. Beaucoup de gens lancent ssh-add alors qu’aucun agent ne tourne, ou alors ils démarrent un agent sans appliquer les variables d’environnement.

Windows : l’agent persiste (souvent le plus simple)

Sur Windows, le service OpenSSH agent peut être configuré pour démarrer automatiquement. Ensuite, tu charges tes clés une fois, et elles reviennent après reboot.

Set-Service ssh-agent -StartupType Automatic Start-Service ssh-agent

Attention : l’agent garde les clés déchiffrées en mémoire via le service. Si ton accès est critique, la clé matérielle reste la meilleure option.

Linux : keychain ou systemd user

Sur Linux, une approche simple consiste à utiliser keychain pour réutiliser un agent existant et éviter de re-taper la passphrase à chaque session.

sudo apt install keychain
# dans ~/.bashrc :
eval "$(keychain --eval --quiet id_ed25519_pc id_ed25519_github)"

Sur certaines configurations desktop, d’autres composants peuvent aussi gérer un agent. L’idée est de garder un contrôle clair sur “qui lance quoi”.

Mode ponctuel : le eval est obligatoire

Pour une tâche isolée, tu peux lancer un agent “jetable” dans ton terminal. Mais fais-le correctement :

eval "$(ssh-agent -s)"

Le eval applique les variables d’environnement dans ton shell courant. Sans ça, ton shell ne sait pas où joindre l’agent, et ssh-add échoue.

Arrêter proprement

Si tu as lancé l’agent proprement, tu peux le tuer avec :

ssh-agent -k

Si tu as lancé sans eval, tu peux te retrouver avec un agent qui tourne “dans le flou”. Dans ce cas, un nettoyage global peut être nécessaire :

pkill -u "$USER" ssh-agent

8) Sécurité ssh-agent : les deux réglages que je fais toujours

ssh-agent est pratique, mais il garde des clés déchiffrées en mémoire. Donc je limite l’exposition.

Timeout sur les clés sensibles

Tu peux demander à l’agent de purger une clé après un délai :

ssh-add -t 8h ~/.ssh/id_ed25519_mon_pc

Tu peux aussi mettre un comportement par défaut dans la config pour éviter les oublis.

Forwarding d’agent : prudence

Le forwarding d’agent (ForwardAgent yes ou ssh -A) permet au serveur distant d’utiliser ton agent pour rebondir ailleurs. C’est pratique, mais si le serveur est compromis, l’attaquant profite de ton agent tant que tu es connecté.

Je préfère une approche plus maîtrisée : ProxyJump pour le rebond, plutôt que le forwarding d’agent.

Checklist : la méthode à appliquer dès maintenant

  • Format : Ed25519 partout.
  • Commande : ssh-keygen -t ed25519 -a 100 -C "..." -f ~/.ssh/nom_explicite.
  • Passphrase : obligatoire, forte, jamais via -N.
  • Nombre de clés : peu. Une par machine cliente, plus une dédiée aux services tiers.
  • Passphrases : une par machine (et éventuellement une distincte pour la clé tierce).
  • Confort : AddKeysToAgent yes + IdentitiesOnly yes quand nécessaire.
  • Rotation / nettoyage : les clés n’expirent pas, donc tu fais un audit et tu révoques vite.
  • Accès sensible : clé matérielle si tu veux le cran au-dessus.

Conclusion : reprendre le contrôle de tes accès

Les clés SSH ne sont pas un “détail de configuration”. Ce sont tes serrures. Et une serrure mal gérée, c’est un accès facile à long terme.

Si tu appliques cette méthode—Ed25519, passphrase, organisation claire, ssh-agent propre et audit régulier—tu réduis drastiquement le risque, tout en gardant un homelab fluide. La prochaine étape logique ? Faire l’inventaire de tes authorized_keys et vérifier que chaque clé correspond encore à une machine que tu contrôles.

Informatique

bbDump : l’alternative moderne à pgAdmin (MCP)

Laisser un commentaire

bbDump fait partie des nouveautés qui méritent qu’on s’y attarde : un gestionnaire PostgreSQL pensé pour remplacer les réflexes CLI (pg_dump, pg_restore, navigation de schéma) par une interface plus directe… et qui va plus loin avec une intégration MCP pour les agents IA.

Ce que bbDump change vraiment par rapport à pgAdmin

On retrouve les fonctions attendues d’un client PostgreSQL : gestion multi-bases organisée par projet, backups (liste, restauration, filtres), et même une visionneuse de logs en temps réel pour suivre les opérations liées à pg_dump.

L’approche “moderne” se voit aussi dans l’ergonomie : navigateur de tables avec édition inline, constructeur de requêtes SQL (visuel + éditeur brut), export CSV, et un visualiseur ERD interactif pour comprendre rapidement une base héritée.

Interface bbDump : gestion PostgreSQL et couche MCP pour agents IA
Interface bbDump : gestion PostgreSQL et couche MCP pour agents IA

Le twist : MCP pour brancher des agents IA sur votre base

Le point le plus intéressant côté veille, c’est l’intégration MCP. bbDump expose 31 outils MCP permettant à des agents (type Claude ou autres LLM) d’interroger la base : consulter le schéma, explorer, et tester des requêtes.

Et surtout, les mutations passent par un mécanisme de confirmation : l’idée est de réduire le risque d’actions destructrices faites “à l’aveugle”.

Sécurité et disponibilité : ce qu’il faut vérifier avant d’adopter

  • Backups chiffrés en AES-256-GCM.
  • Projet jeune : disponible sur macOS et Linux en beta.
  • Windows n’est pas encore supporté.

Si vous administrez PostgreSQL et que vous cherchez une alternative plus fluide, bbDump mérite un test — surtout pour ceux qui veulent combiner DB tooling et agents IA, sans sacrifier la prudence.

Prochaine étape : voir comment l’intégration MCP s’insère dans vos workflows (revue de requêtes, validation, automatisations) et si l’UX tient la distance sur des bases “réelles”.

Source : https://korben.info/bbdump-lalternative-moderne-a-pgadmin-sauce-mcp.html

Informatique, Intelligence artificielle

Synology bascule vers l’IA locale : ce que ça change

Laisser un commentaire

On a longtemps résumé Synology à un petit boîtier rassurant, posé près de la box : on branche, on remplit des disques, et on oublie. Pourtant, lors du Computex 2026, la marque a raconté une autre histoire—et elle est franchement plus ambitieuse. Au cœur de ce virage : l’IA locale Synology et une stratégie qui assume enfin son déplacement vers les professionnels.

Du “NAS domestique” au stockage à grande échelle

Le premier signal n’est pas un slogan, mais un ordre de grandeur : Synology annonce un chiffre d’affaires projeté autour du milliard de dollars pour 2026. Et surtout, la répartition de sa clientèle change de visage : 63 % de l’activité viendrait désormais des professionnels (PME et grandes entreprises), contre 36 % pour le grand public et les prosumers.

Autrement dit, le boîtier du salon n’est plus le centre du récit. La marque évoque aussi des volumes très concrets—3,1 millions de disques expédiés chaque année—et une part significative de capacité de stockage sur site à l’échelle mondiale. On parle donc d’un acteur qui ne joue plus uniquement la carte “simplicité domestique”.

Pourquoi Synology baisse la promesse “grand public”

Ce qui m’a le plus marqué, c’est la franchise du directeur général Europe : le marché grand public ne devrait pas croître “à deux chiffres chaque année”, et le cloud public resterait bon marché. Dans ce contexte, Synology semble considérer que le particulier a déjà atteint un plafond de besoin : “envoyez vos photos”, et le reste glisse vers le streaming.

Cette lucidité explique une stratégie moins “marketing produit” et plus “gestion de base”. La BeeStation, par exemple, n’est pas présentée comme une machine à recruter, mais comme un moyen de maintenir une audience grand public jugée arrivée à maturité.

L’IA locale : le vrai levier (et le bon débat)

Le Computex 2026 met l’accent sur une intelligence artificielle exécutée localement. C’est là que, pour moi, le sujet devient intéressant : l’IA n’est pas seulement une fonctionnalité à ajouter, c’est une façon de repenser la valeur du stockage. Si l’IA s’exécute “chez soi”, alors le NAS redevient plus qu’une armoire : il redevient un poste de traitement, au plus près des données.

Et forcément, ça ouvre une question de fond : le grand public a-t-il envie de gérer davantage qu’un simple archivage ? Les professionnels, eux, ont souvent des contraintes (données, latence, organisation) qui rendent l’“IA locale” plus crédible. La stratégie de Synology ressemble donc à un alignement naturel : viser là où la valeur perçue justifie la complexité.

De BeeStation à BeeCamera : le “tout-en-un” s’étend

La gamme s’étoffe : à côté de BeeStation, une déclinaison BeeStation Plus est annoncée, et l’arrivée de BeeCamera s’appuie sur des caméras domestiques. L’idée est claire : rapprocher la gestion de contenus (photos/vidéos) et des usages “maison” (surveillance) dans une même logique d’écosystème.

Conclusion : un repositionnement assumé

En 2026, Synology ne se cache plus derrière son image de “boîtier discret”. La marque revendique un poids pro croissant, et pousse l’IA locale Synology comme prochaine marche. Pour les utilisateurs, la question n’est plus “est-ce que ça sauvegarde ?”, mais “est-ce que ça transforme mes données en valeur utile ?”. Et c’est, à mon sens, le bon débat.

Ouverture : si l’IA locale devient un standard, les NAS pourraient redevenir des centres de contrôle—pas seulement des coffres.

Source : https://www.clubic.com/dossier-615808-derriere-le-petit-boitier-du-salon-synology-est-devenu-un-geant-du-stockage-et-de-l-ia.html

Informatique

Classement TIOBE 2026 : Python n°1, R progresse

Laisser un commentaire

Le classement TIOBE de mai 2026 vient de tomber et, comme souvent, il donne un bon aperçu des tendances de popularité… avec ses angles morts. Dans cet article, on reprend les points clés : Python reste numéro 1, R gagne du terrain en atteignant son meilleur classement historique (8e), Java prend l’élan avec Java 26, tandis que MATLAB et SAS reculent fortement.

Ce que dit le classement TIOBE en mai 2026

Selon la mise à jour publiée par TIOBE, Python conserve la première place du Programming Community Index. De son côté, R atteint son meilleur classement historique en se hissant à la 8e place. Le rapport indique aussi une dynamique positive pour Java, portée par le lancement de Java 26.

À l’inverse, des reculs marqués pour MATLAB et SAS. L’idée générale qui ressort est celle d’une consolidation autour de langages utilisés dans des contextes variés, notamment côté data/statistiques.

Comment TIOBE calcule son index (et pourquoi il faut le lire avec prudence)

Le classement TIOBE est basé sur un indicateur de popularité : il s’appuie sur le nombre de résultats obtenus par des requêtes contenant le nom d’un langage. Plus précisément, TIOBE agrège des signaux issus de plusieurs moteurs et plateformes (par exemple Google, Google Blogs, MSN, Yahoo!, Baidu, Wikipédia et YouTube), avec une mise à jour mensuelle.

Cette méthode explique pourquoi l’index est à la fois utile et contesté. Plusieurs critiques sont évoquées : la surreprésentation possible des langages utilisés par des non développeurs ou des étudiants (ce qui peut gonfler certains noms comme Python), et le fait que l’index soit international, donc pas forcément aligné avec le marché français.

  • Point fort : repérer des tendances à la hausse ou à la baisse sur le marché international.
  • Point faible : ne pas confondre popularité “mesurée” et adéquation “emploi” ou “projets réels”.
  • Lecture recommandée : considérer TIOBE comme un thermomètre, pas comme un palmarès absolu.

Pourquoi Python reste n°1 (et ce que ça implique)

Le fait que Python conserve la première place n’est pas seulement un détail : ça suggère une stabilité de la demande et de l’intérêt, à la fois pour l’apprentissage, l’écosystème et les usages concrets. Même si le calcul TIOBE n’est pas “parfait”, le signal reste cohérent : Python continue d’être massivement recherché et discuté.

Pour un lecteur, l’implication la plus pragmatique est simple : si vous démarrez, Python reste un choix “faible risque” pour entrer dans de nombreux domaines (data, automatisation, web, scripting). Si vous êtes déjà développeur, l’enjeu n’est pas de “suivre le classement”, mais de vérifier que votre projet tire parti des bibliothèques et des pratiques autour de Python.

R progresse : meilleur historique et montée à la 8e place

L’autre fait marquant de ce classement TIOBE est la performance de R. L’article mentionne qu’il égale son record historique en se classant à la 8e place. Ce signal pointe vers une hausse d’intérêt (ou une meilleure visibilité) autour des usages statistiques et de la data science.

Attention toutefois : “R monte dans TIOBE” ne veut pas dire automatiquement “R recrute plus en France” ou “R est le meilleur choix pour votre contexte”. Ça indique surtout que le langage est davantage recherché/mentionné, ce qui peut refléter des cycles de formation, des publications, des communautés actives ou des projets.

Java prend de l’élan avec Java 26

Le classement TIOBE souligne aussi la progression de Java suite au lancement de Java 26. Autrement dit : l’écosystème Java continue d’être alimenté par des annonces de versions, des retours de communauté et un intérêt durable.

Pour les équipes, le point clé n’est pas de courir après “le numéro de version”, mais de s’assurer que la stack est maintenable, documentée et compatible avec les besoins produit. Dans une logique entreprise, Java reste souvent un langage de fond : la tendance TIOBE peut donc être lue comme un signal de continuité, pas comme un changement radical.

MATLAB et SAS reculent : un signal à contextualiser

Enfin, MATLAB et SAS reculent fortement. Ce type de mouvement peut correspondre à plusieurs réalités : évolution des usages, concurrence d’autres outils/open source, ou déplacement des pratiques de data vers des environnements plus largement adoptés.

Mais là encore, il faut éviter l’interprétation trop directe. Dans certains secteurs, MATLAB ou SAS peuvent rester très présents selon les contraintes réglementaires, les habitudes d’équipe ou la nature des projets. Le classement TIOBE ne remplace donc pas une analyse “terrain” (compétences existantes, besoins métiers, offres d’emploi).

Faut-il choisir un langage en se basant sur TIOBE ?

Mon avis : non, pas uniquement. Le classement TIOBE est intéressant pour comprendre des tendances de popularité, mais il ne dit pas tout sur la valeur d’un langage pour votre cas d’usage. Pour décider, je recommande de croiser au moins trois angles :

  1. Votre objectif : apprentissage, data, web, automatisation, recherche…
  2. Votre contexte : stack existante, contraintes, ressources de l’équipe.
  3. Votre marché : offres d’emploi, bibliothèques disponibles, dynamique de communauté.

Le classement TIOBE sert alors de point de départ : il vous aide à repérer ce qui attire l’attention à l’échelle mondiale. Ensuite, vous validez avec des signaux plus “proches du réel”.

Conclusion : un thermomètre utile, pas une vérité absolue

Le classement TIOBE de mai 2026 confirme une tendance : Python reste au sommet, R progresse fortement (8e), Java avance avec Java 26, tandis que MATLAB et SAS décrochent. L’intérêt principal de ce type d’index est de suivre l’évolution de la popularité.

La meilleure suite, c’est de prendre ces signaux comme une hypothèse à vérifier : regardez les projets autour de vous, les besoins de votre domaine, et la réalité des compétences recherchées. Et si vous deviez apprendre ou consolider un langage cette année, lequel choisiriez-vous — et pourquoi ?

Source : https://programmation.developpez.com/actu/383320/Python-reste-numero-1-R-gagne-en-popularite-et-atteint-son-meilleur-classement-historique-avec-la-8e-place-Java-a-pris-de-l-elan-avec-Java-26-tandis-que-MATLAB-et-SAS-sont-les-grands-perdants-selon-TIOBE/

Informatique

Veille sur le support logiciel libre public

Laisser un commentaire

Le support logiciel libre dans l’administration française fait l’objet d’un travail de veille particulièrement intéressant. Dans le cadre du marché de support au logiciel libre piloté par la DGFiP, des études sont réalisées puis publiées, ce qui donne accès à une matière utile aussi bien pour les acteurs publics que pour les curieux du libre.

L’idée est simple, mais très pertinente : documenter l’état de l’offre sur différents sujets proposés par les administrations. Selon les cas, il peut s’agir d’une veille plutôt stratégique, pour évaluer la maturité d’un domaine fonctionnel précis, ou d’une veille plus technique, avec comparaison détaillée des logiciels existants à partir d’une grille fonctionnelle.

Pourquoi ces veilles sur le support logiciel libre sont utiles

Ce qui est intéressant ici, c’est que ces travaux ne servent pas seulement à informer. Les conclusions peuvent aussi contribuer à décider si un logiciel entre ou non dans le périmètre du marché de support interministériel. On n’est donc pas dans la documentation pour la documentation, mais dans un usage très concret.

Autre bon point : ces études sont publiées par l’administration dans un format bureautique ODT et sous licence CC BY-SA 2.0 FR. C’est cohérent avec l’esprit du sujet, et surtout cela permet la réutilisation de contenus d’intérêt général.

Une ressource à surveiller

Il existe bien un espace public où retrouver ces études pour la période récente : ADULLACT.

  • veille stratégique sur la maturité d’une offre libre ;
  • veille technique avec comparaison fonctionnelle ;
  • publication ouverte par l’administration ;
  • impact possible sur le périmètre du support interministériel.

Je trouve la démarche saine. Trop souvent, on parle du libre de manière théorique. Là, on voit au contraire une approche pragmatique : observer, comparer, publier, puis éventuellement intégrer. Pour qui s’intéresse aux logiciels libres dans le secteur public, c’est clairement une source à garder de côté.

Conclusion : ces études de veille donnent un aperçu concret de la manière dont l’administration évalue le libre. Rien que pour cela, elles méritent le détour.

Sources :

Informatique

OVHcloud et l’euro numérique souverain

Laisser un commentaire

L’euro numérique n’est plus seulement une idée de technocrates bruxellois ou un sujet de conférence entre banquiers centraux. Avec le choix d’OVHcloud par la BCE pour fournir une partie de l’infrastructure cloud souveraine du projet, on passe un cran plus loin : celui de la mise en œuvre concrète. Et ce n’est pas anodin.

Quand l’Europe parle de souveraineté numérique, on a souvent droit à des déclarations ambitieuses, puis à des solutions qui reposent encore sur des briques étrangères. Ici, le signal est au moins plus cohérent : un acteur européen, des serveurs opérés depuis l’Union européenne, et un projet monétaire qui touche directement à l’autonomie stratégique du continent.

OVHcloud entre dans le chantier de l’euro numérique

La BCE a retenu OVHcloud, avec Senacor Technologies, pour participer à l’infrastructure du futur euro numérique. Côté répartition des rôles, Senacor construit le composant technique SEPI, présenté comme un système d’échange sécurisé des informations de paiement. OVHcloud, de son côté, fournit l’infrastructure cloud souveraine sur laquelle une partie de cet ensemble reposera.

Le point mis en avant est clair : l’infrastructure est opérée à 100 % depuis l’Union européenne, avec des serveurs installés en Europe. Dit autrement, la BCE cherche ici à éviter qu’un projet aussi sensible dépende d’un hébergement ou d’une gouvernance technique extra-européenne.

Sur le papier, c’est exactement ce qu’on attend d’un projet de cette nature. On parle quand même d’une future monnaie électronique émise par la Banque centrale européenne, destinée à être utilisée pour payer en boutique, sur Internet ou entre particuliers. Si l’on voulait un cas d’usage où la question du contrôle de l’infrastructure est centrale, difficile de faire mieux.

Pourquoi la souveraineté revient au centre du jeu

Le sujet n’est pas seulement technique. Il est aussi politique, économique et même assez banal dans notre quotidien. Aujourd’hui, une grande partie des paiements par carte en Europe passe encore par des acteurs étrangers, notamment Visa et Mastercard. La source rappelle d’ailleurs que deux tiers des paiements par carte sur le continent transitent par des entreprises non européennes, et que treize pays de la zone euro ne disposent d’aucune solution locale de substitution.

Vu comme ça, l’euro numérique apparaît moins comme un gadget moderne que comme une tentative de reprendre la main sur une fonction essentielle : payer. On peut discuter du calendrier, du coût, de la complexité, mais le diagnostic de dépendance paraît difficile à contester.

Et c’est là que le choix d’OVHcloud prend une portée symbolique. L’Europe ne peut pas expliquer qu’elle veut une monnaie numérique souveraine tout en la faisant reposer sur des infrastructures dont elle ne maîtrise ni totalement l’exploitation, ni les contraintes juridiques, ni les dépendances industrielles. Sur ce point, le choix semble logique.

Ce que l’euro numérique pourrait changer

Dans la présentation du projet, plusieurs promesses reviennent. L’euro numérique doit permettre des paiements en magasin, en ligne, mais aussi des transferts d’argent entre particuliers. La BCE met également en avant un fonctionnement possible hors connexion internet, avec un niveau de discrétion rapproché de celui du cash.

Pour les commerçants, un autre argument est avancé : les frais. Aujourd’hui, chaque paiement par carte entraîne des commissions. Avec l’euro numérique, ces frais seraient plafonnés à un niveau inférieur à ceux pratiqués par les grands réseaux internationaux. Pour les petits commerces, la source évoque même une facture potentiellement divisée par deux.

Sur le principe, cela peut parler à beaucoup de monde :

  • moins de dépendance à des réseaux de paiement étrangers ;
  • des coûts potentiellement réduits pour certains commerçants ;
  • une infrastructure européenne pour un usage monétaire européen ;
  • une continuité de service pensée même sans connexion.

Dit comme ça, le projet coche beaucoup de cases. Reste évidemment la distance entre la promesse et l’exécution, qui est souvent l’endroit où les beaux discours rencontrent la réalité.

Un projet ambitieux, mais loin d’être gratuit

La source rappelle aussi un point moins vendeur : l’adaptation des systèmes bancaires représenterait entre 4 et 6 milliards d’euros d’investissements sur quatre ans. C’est considérable. Et comme souvent, ce genre de transformation ne consiste pas juste à brancher un nouveau service sur un existant bien propre. Il faut intégrer, sécuriser, superviser, faire cohabiter l’ancien et le nouveau, former, tester, auditer.

Autrement dit, le vrai sujet n’est pas seulement de savoir si l’euro numérique est pertinent en théorie. Il est aussi de savoir si l’écosystème bancaire européen est prêt à absorber l’effort technique et financier nécessaire. On parle d’un chantier de fond, pas d’une simple mise à jour logicielle.

Le lancement évoqué pour 2029 montre d’ailleurs que personne n’imagine une bascule rapide. Et c’est probablement une bonne chose. Sur ce type de sujet, aller trop vite serait une erreur.

Une bonne nouvelle, mais pas encore une victoire

Il y a malgré tout une tentation classique : voir dans cette annonce une preuve que la souveraineté numérique européenne est enfin gagnée. Ce serait aller un peu vite. Le choix d’OVHcloud est un signal fort, oui. C’est cohérent avec le discours européen sur l’autonomie stratégique, oui. Mais cela ne règle pas à lui seul toutes les questions autour du projet.

Il reste au moins trois niveaux de prudence à garder en tête. D’abord, le cadre législatif doit encore être adopté. Ensuite, un projet de paiement à l’échelle européenne se juge sur sa robustesse, sa simplicité d’usage et sa confiance perçue par le public. Enfin, la souveraineté ne se décrète pas uniquement parce que les serveurs sont en Europe : elle se construit aussi dans les logiciels, les standards, la gouvernance et la capacité à durer.

Mais pour une fois, on peut au moins dire qu’il y a une forme d’alignement entre le discours et le choix technique. Et dans le numérique européen, ce n’est déjà pas si fréquent.

Ce qu’il faut retenir

L’annonce autour d’OVHcloud et de l’euro numérique ne signifie pas que tout est bouclé. En revanche, elle montre que la BCE avance concrètement, et que la question de l’infrastructure souveraine n’est plus traitée comme un simple argument marketing.

Si le projet aboutit, il pourrait modifier en profondeur la manière dont l’Europe pense ses paiements numériques. Pas en remplaçant du jour au lendemain tous les usages existants, mais en créant une alternative plus directement maîtrisée sur le continent. Et dans le contexte actuel, ce n’est pas un détail, c’est probablement le cœur du sujet.

Source : https://www.clubic.com/actualite-605296-le-francais-ovhcloud-choisi-par-la-bce-pour-fournir-l-infrastructure-souveraine-cloud-de-l-euro-numerique.html

Informatique

Le coût de la Suite numérique de l’État

Laisser un commentaire

La Suite numérique de l’État fait parler d’elle, souvent avec des critiques très tranchées. Trop chère pour certains, pas assez ambitieuse pour d’autres, utile mais encore incomplète pour beaucoup. Comme souvent sur le numérique public, le débat mélange technique, politique, usages et symboles. Le plus utile est donc de revenir aux faits, puis d’essayer de comprendre ce que ce projet dit vraiment de la stratégie numérique de l’État.

À ce stade, on peut déjà retenir une chose simple : il ne s’agit pas seulement d’une collection d’outils, mais d’une tentative de doter les agents publics d’un environnement de travail plus cohérent, fondé sur des logiciels libres et sur une maîtrise plus forte des données.

La Suite numérique de l’État, c’est quoi exactement ?

La Suite numérique de l’État est portée par la DINUM, la direction interministérielle du numérique. Son objectif est de proposer aux agents publics une série d’outils collaboratifs couvrant les usages les plus courants du travail quotidien.

D’après les éléments disponibles, cet ensemble comprend notamment :

  • Tchap, une messagerie instantanée reposant sur Matrix ;
  • Visio, pour la visioconférence ;
  • France Transfert, pour l’envoi de fichiers volumineux ;
  • Messagerie, pour les mails, contacts et rendez-vous ;
  • Fichiers, pour le stockage et le partage ;
  • Docs et Grist, pour l’édition collaborative et la gestion de données ;
  • un assistant IA présenté comme basé sur Mistral.

Le point important est que ces briques s’inscrivent dans une logique de logiciels libres. Cela ne signifie pas que tout est simple, parfait ou immédiatement interchangeable avec les suites des grands acteurs privés. En revanche, cela indique une orientation claire : réduire certaines dépendances technologiques et mieux contrôler les infrastructures et les données utilisées par l’administration.

Pourquoi ce projet suscite autant de débats ?

Le débat autour de la Suite numérique de l’État ne porte pas uniquement sur les fonctionnalités. Il touche à une question plus large : comment un État doit-il investir dans le numérique ? Faut-il acheter des solutions déjà dominantes sur le marché, quitte à renforcer la dépendance à quelques grands fournisseurs ? Ou faut-il financer des communs numériques, plus lents à construire mais potentiellement plus durables et plus cohérents avec l’intérêt général ?

Certaines critiques passent à côté de l’enjeu principal : construire des alternatives publiques et libres ne peut pas être jugé uniquement avec les réflexes habituels du marché privé, où l’on compare un coût immédiat à un service déjà industrialisé à très grande échelle.

Autrement dit, si l’on attend d’un projet public libre qu’il rivalise instantanément avec les plateformes les plus puissantes du marché, on risque de conclure trop vite à l’échec. La question pertinente est aussi celle de la capacité collective que l’on construit : maîtrise technique, réutilisation, interopérabilité, souveraineté sur les données et possibilité d’amélioration continue.

Le sujet du coût : ce que l’on peut dire prudemment

Le coût est évidemment au centre des discussions. D’après la contrainte fournie ici, la suite numérique a un coût d’un peu moins de 15 M€ pour une utilisation en moyenne par moins de 200 000 agents, soit environ 75 € par agent et par an. Présenté ainsi, le chiffre peut sembler élevé ou au contraire raisonnable selon le point de comparaison choisi.

Il faut donc éviter deux excès. Le premier serait de dire que ce montant prouve à lui seul un gaspillage. Le second serait d’affirmer qu’il valide automatiquement la stratégie. Un coût unitaire n’a de sens qu’en tenant compte de plusieurs éléments : le périmètre exact des services, le niveau de sécurité attendu, les coûts d’hébergement, de maintenance, d’intégration, d’accompagnement et la capacité du projet à produire des briques réutilisables ailleurs.

Le rapport de la Cour des comptes cité parmi les sources rappelle plus largement que le pilotage de la transformation numérique de l’État est un sujet complexe. Cela invite à une lecture prudente : un chiffre isolé éclaire une partie du problème, mais ne suffit pas à résumer la valeur d’une politique publique numérique.

Coût estimé de la Suite numérique de l’État par agent et par an
Coût estimé de la Suite numérique de l’État par agent et par an

Au-delà du prix, la vraie question est celle des communs

Le point le plus intéressant est sans doute là. L’alternative aux grandes plateformes ne viendrait pas d’un simple « champion européen » copiant les logiques des Big Tech à une autre échelle. Elle viendrait plutôt des communs numériques : logiciels libres, infrastructures interopérables, gouvernance partagée, ancrage dans l’intérêt général.

Cette idée change la manière d’évaluer la Suite numérique de l’État. Si l’on raisonne uniquement en produit fini, on regardera surtout les manques, les retards ou l’adoption encore limitée. Si l’on raisonne en communs, on regarde aussi autre chose :

  • la réutilisabilité du code ;
  • la réduction des dépendances ;
  • la transparence technique ;
  • la possibilité de mutualiser entre administrations ;
  • la contribution à un écosystème libre plus large.

Ce n’est pas une garantie de succès. C’est simplement une autre grille de lecture, probablement plus adaptée à un projet public de cette nature.

Pourquoi l’adoption reste un enjeu central

Même avec une bonne intention politique, un outil ne vaut que s’il est utilisé. Or les sources évoquent une utilisation moyenne par moins de 200 000 agents, ce qui montre qu’on reste loin d’une généralisation à l’ensemble de la fonction publique. Cela pose une question très concrète : comment faire adopter une suite publique quand les habitudes, les outils existants et les contraintes de terrain sont déjà très installés ?

Dans ce type de projet, la difficulté n’est pas seulement de développer des services. Il faut aussi convaincre, former, intégrer aux pratiques réelles, garantir la fiabilité et éviter que l’outil public soit perçu comme une solution imposée mais moins pratique. C’est souvent là que se joue la réussite.

En clair, la Suite numérique de l’État ne peut pas être évaluée uniquement sur son intention politique. Elle doit aussi démontrer sa qualité d’usage. Sur ce point, la critique reste légitime : un commun numérique utile doit être non seulement libre, mais aussi pratique.

Ce qu’il faut retenir

La Suite numérique de l’État est à la fois un projet d’outillage administratif et un révélateur d’un débat plus profond sur le numérique public. Oui, son coût interroge. Oui, son niveau d’adoption reste un sujet. Mais non, on ne peut pas résumer le dossier à une simple dépense par agent ou à une opposition caricaturale entre efficacité et logiciel libre.

Le vrai sujet est peut-être plus ambitieux : savoir si l’État veut seulement consommer des solutions numériques, ou aussi contribuer à construire des communs sur lesquels il garde une prise. C’est plus long, plus difficile, parfois plus ingrat. Mais c’est probablement là que se joue une part importante de la crédibilité d’une politique numérique publique.

Et comme souvent en informatique, tout l’enjeu n’est pas seulement d’avoir un outil. C’est de savoir dans quelle dépendance on entre en l’utilisant.

Sources :

Informatique

DevOps et l’infrastructure as code par l’exemple

Laisser un commentaire

L’infrastructure as code fait partie intégrante du DevOps. C’est en approfondissant mes recherches sur ce dernier que je suis tombé sur ce très bon article qui décrit de manière très simple comment décrire son architecture en écrivant ses fichiers de conf.

L’auteur y parle de Terraform, l’outil n°1 pour faire de l’IaC.

J’invite d’ailleurs à parcourir par la suite le reste du blog qui est très bon et très facile à lire sur tout ce qui est dév avec divers conseils ou retours d’expérience.

Informatique

Comparaison des performances entre ionic et react native

Laisser un commentaire

Avant de découvrir Flutter et que Google sorte une version stable, je m’étais d’abord penché sur Ionic pour un développement mobile rapide et qui faisait largement le job, mais pour lequel j’ai rencontré des gros problèmes de performance sur des tablettes avec des versions Android assez vieilles (4.4, 5), ce qu’on trouve assez largement sur des anciens modèles. Et comme on ne peut pas mettre à jour la version d’Android, reste plus qu’à voir l’optimisation côté application.

J’ai donc pas mal parcouru de sites à la recherche de performance, puis de comparaison avec React Native de Facebook, qui avait une autre approche que Ionic, une sorte d’application hybride entre du code native et du code javascript.

Le problème que j’ai rencontré avec React Native, c’est le design, où il faut faire pas mal de CSS, adapter le peu de bibliothèques, problème qu’on a moins avec Ionic, qui a un grand panel de librairies déjà dessinées.

Et je suis tombé sur ce site qui fait le point sur les performances entre Ionic et React Native en comparant pas mal d’éléments.
Pour résumer, pour la performance c’est React Native, pour une application facile à prendre en main et rapide à faire, c’est Ionic. Mais comme dit au début, cela date, et maintenant il y a Flutter.