Stirling PDF rend son SSO OAuth gratuit, Ubuntu accélère la livraison de ses noyaux et Tailscale prépare une meilleure utilisation des machines qui servent de routeurs. Trois sujets assez concrets pour ceux qui entretiennent leurs propres services.
Cette semaine pose aussi deux questions de matériel : ce qu’on peut encore modifier sur un Raspberry Pi, et ce que le projet de rachat de Shelly par Schneider Electric annonce réellement. Sélection du 18 au 25 septembre 2026, avec les versions et calendriers vérifiés au moment de la rédaction.
En bref#
- Stirling PDF 3.0 : SSO OAuth gratuit, nouveau Processor pour les traitements en lot, mais une enveloppe gratuite de 1 000 PDF automatisés par mois.
- Ubuntu : des cycles de préparation et de test de deux semaines, décalés pour publier un noyau chaque semaine. La transition commence le 28 septembre.
- Tailscale : moins de copies mémoire et davantage de parallélisme annoncés. Une partie vise la 1.104, le multi-queue viendra après.
- Raspberry Pi 5 : les cartes dont la RAM a été remplacée peuvent rencontrer des problèmes avec les firmwares récents. Le sujet revient dans l’actualité, le comportement est plus ancien.
- Shelly : Schneider Electric prépare une offre de rachat. La clôture reste conditionnelle, attendue au premier trimestre 2027.
Stirling PDF 3 : le SSO gratuit, l’automatisation à compter#
La 3.0.0, publiée le 24 septembre, rend le SSO OAuth accessible gratuitement. Pour une instance partagée déjà équipée d’un fournisseur d’identité, c’est une bonne raison de regarder cette version : plus besoin d’une offre payante pour cette fonction. L’éditeur de texte sort aussi de son statut alpha. Notes de version
L’autre ajout est Processor. On lui donne une source, des opérations et une destination : par exemple surveiller un dossier de scans, lancer l’OCR, puis déposer les documents traités dans une archive. Les traitements peuvent partir d’un dossier, d’un stockage distant ou d’un webhook. L’IA est facultative et désactivée par défaut. Guide Processor, release
Le point à vérifier avant de migrer une automatisation existante, c’est le volume :
| Usage | Conditions annoncées en 3.0 |
|---|---|
| Utilisation normale de l’éditeur PDF | Gratuite et illimitée |
| Traitements automatisés via Processor, API et fonctions IA | 1 000 PDF par mois inclus gratuitement |
| Serveur lié à un compte stirling.com | 500 PDF supplémentaires par mois |
Une tâche qui traite quelques dizaines de factures et un script qui convertit toute une GED ne sont donc pas dans la même situation. Les appels API entrent dans le quota, pas seulement les nouveaux workflows.
Processor demande aussi une instance avec connexion utilisateur. En auto-hébergement, l’administration des sources et des pipelines revient aux administrateurs. Pour surveiller un dossier du serveur, il faut le monter dans le conteneur, régler les permissions et autoriser son répertoire parent dans policies.allowedFolderRoots. Une instance sans login ne donnera pas accès à Processor. Configuration et accès
Ubuntu : des noyaux publiés chaque semaine, après la transition#
Canonical abandonne son organisation avec un cycle régulier de quatre semaines et un cycle de sécurité de deux semaines. Le nouveau modèle utilise des cycles de deux semaines qui se chevauchent : une semaine de préparation, une semaine de certification et de tests de régression. En lançant un cycle chaque semaine, les publications deviennent hebdomadaires. Annonce Canonical
Le calendrier annoncé est précis :
- 28 septembre : début du premier cycle de deux semaines ;
- 12 octobre : début du deuxième, encore consécutif au précédent ;
- 26 octobre : début des cycles qui se chevauchent.
Au 25 septembre, ce fonctionnement n’est donc pas encore en place. Calendrier de l’équipe noyau
Pour l’exploitation, cela justifie de revoir une maintenance qui ne regarderait les noyaux qu’une fois par mois. Le gain dépendra aussi de la capacité à tester puis à démarrer effectivement le nouveau noyau. Installer le paquet et continuer à faire tourner l’ancien pendant six semaines limite forcément l’intérêt du changement.
Canonical propose également les candidats dans -proposed dès la fin de la préparation, avant la certification complète. C’est une possibilité pour un environnement qui assume ses propres tests d’acceptation, pas le dépôt à activer partout pour obtenir les correctifs plus vite. Le calendrier de publication n’est pas non plus une garantie de correction de chaque CVE sous sept jours.
Tailscale : mieux exploiter les routeurs déjà en place#
Le billet du 22 septembre vise notamment les subnet routers, les connecteurs applicatifs et les nœuds de sortie. Tailscale réduit les copies de petits paquets dans de gros buffers, raccourcit certaines files et prépare plusieurs files de traitement en parallèle. Chaque flux conserve son ordre, tandis que différents flux peuvent utiliser plusieurs cœurs.
Ce qui intéresse ici, c’est la capacité agrégée d’une machine qui route beaucoup de connexions. Cela ne promet pas de multiplier le débit d’un téléchargement isolé.
Attention au calendrier : la réduction mémoire sous Linux et Android est attendue en 1.104. Le multi-queue est prévu dans une version ultérieure. Le cache local de la carte des pairs, la netmap, existe derrière une option d’activation et doit devenir actif par défaut en 1.104 après validation ; les clients mobiles suivront plus tard. Annonce et calendrier
Ce cache doit aider un appareil déjà connu du réseau à redémarrer lorsque le plan de contrôle répond mal. Il nécessite une première connexion réussie et du stockage persistant.
Avant d’attribuer un débit décevant au client, vérifiez le chemin réellement utilisé. Remplacez nom-du-pair par un appareil de votre réseau Tailscale :
tailscale status
tailscale ping nom-du-pair
tailscale netcheckstatus distingue une liaison directe, un relais DERP et un relais fourni par un autre pair. ping aide à observer l’établissement du chemin ; netcheck renseigne notamment sur l’accès UDP et les relais. Ce sont des diagnostics de connectivité, pas des mesures de débit. Référence CLI
Raspberry Pi 5 : vérifier ce qu’on achète, surtout d’occasion#
Le sujet de la RAM remplacée revient cette semaine, mais il ne faut pas le présenter comme une restriction apparue vendredi. Un ticket ouvert en octobre 2025 décrit déjà un Pi 5 incapable de démarrer avec une puce mémoire remplacée et des versions d’EEPROM à partir de septembre 2024.
Les mainteneurs y identifient une carte probablement modifiée par le vendeur. Ils expliquent qu’un remplacement de SDRAM n’a pas suivi leur validation matérielle et peut être incompatible avec des changements de firmware ou de configuration d’usine. Leur recommandation dans ce cas est de demander un remboursement. Signalement et réponses des mainteneurs
Pour un achat d’occasion, la capacité affichée par Linux ne suffit donc pas à établir que la carte correspond à la variante vendue. Sous Raspberry Pi OS, le modèle et le code de révision se lisent sans rien modifier :
awk '/^(Model|Revision)[[:space:]]*:/ {print}' /proc/cpuinfoComparez ce code à la table officielle des révisions. Il aide à identifier la variante d’origine, sans certifier à lui seul l’état physique de la carte. Si une machine vendue comme neuve exige un vieux bootloader pour démarrer, c’est au vendeur de s’expliquer.
Shelly et Schneider : un accord de rachat, encore sous conditions#
L’annonce du 24 septembre porte sur un accord préparant une offre publique de rachat. Schneider Electric envisage de proposer 70 euros par action, pour une valorisation d’environ 1,2 milliard d’euros. La clôture est attendue au premier trimestre 2027, sous réserve des autorisations et d’un seuil d’acceptation de 95 %.
Le communiqué précise qu’au moment de sa publication, aucune offre n’est encore enregistrée ni publiée. Dire que Shelly appartient déjà à Schneider irait donc trop vite. Communiqué Shelly
Pour la domotique, la question utile reste le fonctionnement local. L’intégration Shelly de Home Assistant communique avec les appareils sur le réseau local, avec des différences de protocole selon les générations. Documentation de l’intégration
L’annonce ne permet de conclure ni à une fermeture des API, ni à une garantie sur leur maintien à long terme. Si vous dépendez de ces modules, un essai avec leur accès Internet temporairement coupé, tout en conservant le réseau local, dira déjà quelles automatisations reposent encore sur le cloud. À faire sur un équipement sans fonction critique, en prévoyant de rétablir l’accès après le test.
Autres nouvelles à retenir#
Nextcloud 35.0.1, publiée le 24 septembre, corrige notamment la conservation des liens de partage lors d’un transfert de propriété et rétablit le transfert de l’ensemble des fichiers. Pour les instances déjà passées en 35, ce sont deux parcours à retester après mise à jour si vous les utilisez lors des départs d’utilisateurs. Notes de version
KeePassXC 2.8.0-beta1 apporte l’Auto-Type sous Wayland via les portails XDG, le passage à Qt 6 et le déverrouillage rapide via Polkit sous Linux. C’est bien une bêta, publiée le 23 septembre. Pour essayer l’Auto-Type avec votre environnement de bureau, utilisez une copie de votre base ; ce n’est pas encore la sortie stable de la 2.8. Annonce, préversion
undb a été archivé le 22 septembre. Son README indique désormais que le projet a déménagé vers Teable. Il ne fournit pas de procédure de migration des données. Pour une instance existante, commencez par inventorier les exports et les intégrations dont vous dépendez avant d’envisager un remplacement : le lien vers Teable ne prouve pas la compatibilité de vos bases. Dépôt undb
Deux projets à essayer#
Floci pour les tests AWS locaux#
Floci fournit un émulateur AWS local sous licence MIT, utilisable depuis les SDK, l’AWS CLI ou Terraform sur http://localhost:4566, sans compte cloud. Un bon candidat pour isoler des tests S3, SQS ou DynamoDB dans une CI.
La couverture varie suivant les services : certains démarrent de vrais conteneurs, d’autres renvoient des réponses simulées. Un test fonctionnel réussi ne valide donc pas à lui seul le comportement du service AWS réel. La persistance est également en mémoire par défaut. Pour un lab durable, choisissez explicitement le mode de stockage ; pour une CI jetable, ce défaut peut être précisément ce qu’il faut. Configuration
LLDAP pour centraliser quelques comptes#
LLDAP garde un périmètre assez lisible : utilisateurs, groupes, interface web et authentification LDAP simplifiée. SQLite suffit par défaut, avec PostgreSQL ou MySQL/MariaDB possibles.
Ce n’est pas un serveur LDAP complet. Pour fournir du SSO OAuth/OpenID, le projet propose de l’associer à un composant comme Authelia ou Keycloak. Si votre besoin consiste surtout à partager les mêmes comptes entre quelques applications, cette séparation mérite un essai. Vérifiez d’abord la liste des configurations compatibles, puis testez avec une application secondaire avant d’en faire la source d’identité de tous vos services.
Conclusion#
La vérification la plus immédiate concerne les scripts qui appellent Stirling PDF : comptez leurs documents avant de passer en 3.0. Pour les hôtes Ubuntu, les prochaines semaines donnent surtout l’occasion d’ajuster les fenêtres de maintenance au nouveau rythme des noyaux.
Sources#
- Stirling PDF - release 3.0.0
- Stirling PDF - présentation de Processor
- Stirling PDF - configuration et droits d’accès
- Canonical - nouvelle stratégie de publication des noyaux
- Ubuntu - calendrier de transition des cycles SRU
- Tailscale - optimisations et calendrier annoncé
- Tailscale - référence des commandes de diagnostic
- Raspberry Pi - ticket EEPROM et réponses des mainteneurs
- Raspberry Pi - codes de révision des cartes
- Shelly - accord préparant l’offre de Schneider Electric
- Home Assistant - intégration Shelly
- Nextcloud - release 35.0.1
- KeePassXC - annonce de la 2.8.0 bêta 1
- KeePassXC - release 2.8.0-beta1
- undb - dépôt archivé et renvoi vers Teable
- Floci - dépôt et services pris en charge
- Floci - variables de configuration et stockage
- LLDAP - périmètre et architecture
- LLDAP - exemples d’intégration