Pendant qu’Apple peaufine son IA maison pour Xcode (sans date de sortie, évidemment), Microsoft vient tranquillou installer ses petites affaires dans l’écosystème le plus verrouillé du marché en sortant son extension officielle Github Copilot pour Xcode , pile-poil au moment où les rumeurs nous soufflent qu’Apple travaille aussi sur sa propre solution locale.

Cette extension de Github pour Xcode propose trois fonctionnalités principales. Tout d’abord de la complétion de code en temps réel. Ensuite, pendant que vous tapez, un tchat vous permet de poser des questions sur votre code, et il y a également un mode Agent qui peut modifier directement vos fichiers et lancer des commandes terminal. C’est gratuit jusqu’à 2000 complétions et 50 messages tchat par mois, donc largement de quoi rendre accro la majorité des devs iOS avant qu’Apple ne sorte son propre truc !

Maintenant pour utiliser un outil Microsoft dans un IDE Apple, vous devez accorder trois permissions macOS sacrées : Background, Accessibilité, et Xcode Source Editor Extension. Hé oui, Apple force littéralement ses développeurs à ouvrir toutes ces portes et niveau permissions, c’est l’Accessibilité qui pose régulièrement problème, car faut souvent la désactiver puis la réactiver pour que ça fonctionne correctement.

Ensuite l’installation est assez classique. Soit via Homebrew ou en téléchargeant le DMG directement depuis le dépôt GitHub.

brew install --cask github-copilot-for-xcode

Vous avez déjà passé plus de temps à configurer Sphinx qu’à coder votre projet Python ? Bienvenue au club !

Et oui, paradoxalement, parfois documenter son code devient plus compliqué que d’écrire le code… Vous voulez juste afficher vos docstrings joliment, mais avant ça il faut vous taper 200 pages de doc, choisir parmi 47 thèmes, configurer des dizaines d’extensions et comprendre la syntaxe reStructuredText. Breeeef, la flemme !

Heureusement, il existe une alternative qui va vous réconcilier avec la documentation : pdoc.

pdoc, c’est un outil de documentation Python qui ne nécessite pas de documentation. Vous tapez simple pdoc votre_module et c’est tout. Pas de fichier de config interminable, pas de choix existentiels entre différents builders, pas de migration depuis votre version de Sphinx de 2018 qui refuse de compiler.

Ça génère directement une belle doc à partir de votre code existant !!

Si vous avez déjà écrit des docstrings propres et utilisé les type annotations de Python, vous avez déjà fait 100% du boulot car pdoc se contente de prendre ce qui existe et de l’afficher élégamment. Pas de traduction, pas de réécriture, pas de fichiers .rst à maintenir en parallèle de votre code.

Votre code EST la documentation et ça c’est beau !

L’outil comprend les docstrings au format numpydoc et Google-style, fait des liens automatiques entre les identifiants, respecte votre variable __all__ et génère du HTML standalone que vous pouvez héberger n’importe où. Il y a même un serveur web intégré avec live reload pour développer votre doc en temps réel.

Pour mettre ça en place, faut installer pdoc avec

pip install pdoc

Puis vous lancez

pdoc ./votre_projet.py

ou

pdoc nom_de_votre_module

Et c’est tout !

Bien sûr si vous bossez sur un gros projet avec des besoins spécifiques, des guides utilisateurs complexes, des dizaines de pages de tutoriels et une doc multilingue, Sphinx reste le roi, mais pour la grande majorité des projets Python, ceux qui ont juste besoin d’une doc API claire et lisible, pdoc fait ça comme un chef, sans que vous ayez besoin d’un doctorat en outil de documentation.

Bref, si vous en avez marre de passer plus de temps sur votre documentation que sur votre code, pdoc mérite le détour car documenter son code devrait être aussi simple que de le coder, non ?

Pour tester pdoc, direction pdoc.dev ou directement le repo GitHub .

Vous connaissez ces outils qui promettent de créer des apps web juste en discutant avec une IA ? Genre Lovable, v0, Bolt, Replit…etc. C’est magique, sauf que tout tourne dans le cloud, vos données passent par leurs serveurs et vous êtes du coup enfermés dans leur écosystème.

Hé bien Dyad fait la même chose, mais un peu différemment puisque tout tourne en local sur votre machine. En plus c’est open-source et c’est gratuit.

Et si je vous disais qu’il existe un futur où vous allez pouvoir vous connecter en SSH à votre serveur de production avec votre compte Google et que celui-ci serait totalement invisible aux yeux du monde ?

Et bien ça arrive bientôt et ça s’appelle SSH3 !

Alors déjà, pas de panique, je vais pas vous sortir le speech classique du “Oh regardez, un nouveau protocole qui va révolutionner le monde”. Non non, l’histoire est beaucoup plus tordue que ça car SSH3, c’est un symptôme d’un phénomène beaucoup plus gros qui est en train de se passer sous notre nez et qui est la “webisation” d’Internet (oui, je viens d’inventer ce mot).

Car pendant que tout le monde s’excitait tous sur ChatGPT et les IA génératives, des chercheurs belges de l’UCLouvain étaient tranquillement en train de planifier la disparition des serveurs SSH de la surface d’Internet. Et je dis bien “disparaître” dans le sens où votre serveur devient invisible aux scans de ports , car votre serveur SSH peut maintenant se planquer derrière ce qui ressemble à un banal site web.

Pour réussir ce tour de magie, SSH3 utilise HTTP/3 et QUIC au lieu du bon vieux protocole SSH traditionnel. Et là vous me dites “Mais Korben, c’est quoi le rapport avec l’invisibilité ?” Bah c’est simple, comme SSH3 tourne sur les mêmes ports que n’importe quel site HTTPS, impossible de distinguer un serveur SSH3 d’un serveur web lambda. Vous pourriez même planquer votre serveur SSH derrière une URL secrète… Tentez ensuite un scan de ports, et vous ne verrez rien de plus qu’un stupide serveur web…

Ce que j’appelle “webisation”, c’est en fait l’absorption totale de l’infrastructure système par les technologies du web. Et même SSH, le protocole le plus fondamental de l’administration système présent depuis 1995, va devoir capituler face à HTTP/3.

C’est la victoire finale du navigateur sur le terminal, et personne n’en cause vraiment… Avec SSH3, vous allez donc pouvoir utiliser vos certificats Let’s Encrypt pour authentifier votre serveur et le GitHub du projet explique que c’est plus sécurisé que les clés d’hôtes SSH classiques car votre terminal vérifiera le certificat comme le fait votre navigateur.

Mais attendez, le délire va encore plus loin puisque OAuth 2.0 et OpenID Connect sont également supportés nativement. Vous allez donc pouvoir vous connecter à votre serveur de prod avec votre compte Google, Microsoft ou GitHub. Et si j’en crois le draft IETF , c’est parfaitement légitime et sécurisé grâce à l’authentification HTTP standard.

Alors évidemment, l’idée de se logger sur un serveur critique avec son compte Gmail, ça peut faire peur mais on fait déjà confiance à ces mêmes providers pour notre authentification partout ailleurs, donc un de plus ou un de moins… Puis j’imagine que vous pourrez aussi mettre en place votre propre provider, ce qui vous permettra d’éviter les GAFAM tout en ayant une gestion plus simple des accès à vos machines.

Au niveau perfs, SSH3 établit une connexion en seulement 3 round-trips contre 5 à 7 pour SSH classique. Sur une connexion avec 100ms de latence, ça fait une différence énorme. Et en bonus SSH3 supporte le port forwarding UDP en plus du TCP. Cela veut dire que vous pouvez enfin “tunneler” du QUIC, du DNS ou du RTP correctement… Ce projet a explosé en décembre 2023 quand François Michel et Olivier Bonaventure ont publié leur papier mais attention, c’est encore expérimental. Les développeurs le répètent partout : Ne mettez pas ça en prod tout de suite !

Alors est-ce qu’on doit s’inquiéter de cette uniformisation des protocoles ?

Peut-être car si tout le monde utilise les mêmes briques de base, une faille dans QUIC ou HTTP/3 pourrait affecter absolument TOUT. Mais d’un autre côté, concentrer les efforts de sécurité sur moins de protocoles, c’est aussi moins de surface d’attaque à surveiller.

Maintenant pour tester SSH3, c’est simple si vous avez Go installé :

go install github.com/francoismichel/ssh3/cmd/...@latest

`ssh3-server -generate-selfsigned-cert localhost`

`ssh3 user@server`

Et si je vous disais que pendant que vous galérez avec PuTTY et son interface à la Windows 95, ou que vous payez 119 balles pour SecureCRT, il existe un gestionnaire SSH moderne, gratuit et absolument magnifique qui attend tranquillement que quelqu’un le remarque ?

Hé bien c’est exactement ce qui se passe avec SSH Pilot dispo pour Linux et macOS, et je trouve ça vraiment bizarre que personne n’en parle. Quand je suis tombé dessus, c’est vrai que j’ai cru à un énième fork de Terminator ou un wrapper autour de tmux, mais non, c’est un vrai gestionnaire de connexions SSH développé par mfat , avec une interface moderne en libadwaita/GTK4, c’est à dire le truc le plus propre que GNOME ait sorti ces dernières années.

Alors j’ai creusé un peu, je l’ai installé, et là, révélation. Cette appli fait TOUT ce qu’on attend d’un gestionnaire SSH moderne : des onglets pour jongler entre les connexions, un gestionnaire SFTP intégré qui s’ouvre direct dans Nautilus, la génération de paires de clés en deux clics, le port forwarding (local, remote, dynamic), et même le regroupement de serveurs pour ceux qui gèrent des “fermes” entières. Ah et toutes les infos de config sont chiffrées sur votre disque dur.

On peut aussi naviguer entièrement au clavier dans l’appli, ce qui est super pratique. Ctrl+L pour passer de la liste des serveurs au terminal, Ctrl+F4 pour fermer un onglet, Alt+flèches pour switcher entre les tabs. C’est tellement bien pensé que ça en devient suspect ^^.

Car quand on gère plusieurs serveurs, on s’y perd vite si on n’est pas organisé ! On jongle avec des dizaines de connexions SSH, on tape des alias bash à rallonge, on installe des extensions tmux incompréhensibles…

Alors pourquoi SSH Pilot reste si peu connu alors qu’il est trop méga super génial ??? Hé bien j’ai ma petite théorie…

Dans le monde Linux, on a tellement d’alternatives pour chaque truc qu’on finit par se noyer. Quand on cherche un client SSH, on a PuTTY, KiTTY, SuperPuTTY, mTPuTTY, Solar-PuTTY, Bitvise, Tabby, MobaXterm, Termius, SecureCRT… et j’en passe. Trop de choix qui tue le choix !

Bref, jetez un oeil SSH Pilot, ça vous changera des client SSH avec une interface de Minitel.