Vous en avez marre des services de partage de code tout pourris qui vous demandent de vous créer un compte, ou de lier votre GitHub, et qui ensuite vous bombarde de bannières pubs ?

Hé bien y’a une alternative plutôt cool qui va vous plaire.

Ça s’appelle pbnj (oui, comme le sandwich au beurre de cacahuète - Peanut Butter aNd Jelly), et c’est un pastebin auto-hébergé qui vous permet de partager du code en tout simplicité. Pas de prise de chou avec de la gestion de users ou ce genre de choses… Vous y balancez du code et vous récupérez une URL à envoyer à vos amis.

Le truc sympa, c’est que ça génère des URLs faciles à retenir au lieu des classiques suites de caractères aléatoires. Comme ça vous avez des trucs du genre “coucou-tu-veux-mon-blog” plutôt que “x7f9k2m8”. Bon ok c’est un peu plus long, mais au moins vous pouvez le retenir ou le donner par téléphone sans épeler chaque lettre. Vous pouvez tester ce que ça donne en cliquant ici .

Côté fonctionnalités, on a de quoi faire avec de la coloration syntaxique dans plus de 100 langages différents avec 12 thèmes . Y’a aussi un outil en ligne de commande qui s’installe via npm et qui permet de balancer un fichier en une commande comme ceci :

`pbnj monfichier.py`

`npm install -g @pbnjs/cli`

`pbnj --init`

Vous développez une app SwiftUI et Claude vous balance du NavigationView alors qu’Apple recommande NavigationStack depuis la sorite d’iOS 16 ? Ou encore il vous sort @ObservableObject et @Published alors qu’on est passé à @Observable ?

Bienvenue dans le club des devs qui passent plus de temps à corriger les hallucinations de leur IA qu’à coder…

Ce problème, Aleahim, un développeuse macOS, en a eu marre alors elle a créé Cupertino, un serveur MCP qui donne accès à Claude à plus de 22 000 pages de documentation Apple en local. Plus besoin d’aller sur le net, et surtout plus d’excuses pour mélanger du code iOS 12 avec du SwiftUI moderne.

Ainsi, au lieu de laisser Claude deviner les API (et se planter une fois sur deux), on lui file l’accès direct à la vraie doc. Les 261 frameworks Apple sont là, indexés dans une base SQLite locale, avec un moteur de recherche full-text qui répond en moins de 100ms. SwiftUI, UIKit, AppKit, Foundation, Core ML, ARKit… tout y est.

L’écosystème se découpe ensuite en plusieurs repos GitHub. D’abord le serveur MCP principal qui fait le boulot d’indexation, ensuite un repo avec la doc pré-crawlée (parce que se taper 20 heures de téléchargement, merci mais non merci), et une collection de 606 projets d’exemple Apple officiels pour la route.

De quoi transformer Claude en assistant qui connaît VRAIMENT la plateforme.

Si ça vous intéresse, sachez qu’avant de vous lancer, faut être sur macOS 15 minimum avec Xcode 16 et Swift 6.2+. Côté espace disque, prévoyez 2-3 GB. Et si vous avez déjà bidouillé dans le terminal, que vous connaissez Git et que vous avez Claude Code installé, vous êtes bons. Comptez environ une quinzaine de minutes pour tout mettre en place.

Et rassurez-vous, je ne vous laisse pas tomber, on va attaquer l’installation ensemble. D’abord, récupérez le projet et compilez-le :

git clone https://github.com/mihaelamj/cupertino.git
cd cupertino
make build
sudo make install

git clone https://github.com/mihaelamj/cupertino-docs.git ~/.cupertino

# Swift Evolution, ~5 minutes
cupertino fetch --type evolution
# Doc complète, ~20-24h
cupertino fetch --type docs
# Sample code Apple, ~4 minutes
cupertino fetch --type samples

cupertino save

cupertino serve

claude mcp add cupertino --scope user -- /usr/local/bin/cupertino

L’accessibilité web c’est comme le tri sélectif… tout le monde dit que c’est génial mais azy, j’ai pas le temps. Et pourtant, c’est super important car près de 80% des pages web ont des problèmes de contraste de texte.

C’est le souci noumber ouane détecté sur le million de sites analysés chaque année par WebAIM . En gros, si vous avez un site, y’a de fortes chances que certains visiteurs galèrent à lire votre contenu, et je ne vous parle pas uniquement des personnes malvoyantes, hein… y’a aussi le daltonisme qui touche environ 8% des hommes et 0,5% des femmes. Rajoutez à ça les gens qui lisent leur téléphone en plein soleil, ceux qui ont une dalle de laptop toute pourrie, et vous comprendrez vite que le problème concerne pas mal de monde.

Alors est ce que vous connaissez les normes WCAG ?

Hé bien c’est le standard international pour l’accessibilité web. Ainsi pour être conforme au niveau AA (le minimum recommandé), votre texte doit avoir un ratio de contraste d’au moins 4,5:1 avec son arrière-plan. Pour le niveau AAA (l’idéal), c’est 7:1. Et là vous vous dites “super, je vais calculer ça à la main pour mes 47 couleurs de palette, mais va bien te faire cuire le cul, Korben”. (Oui, c’est comme ça que je vous imagine quand vous lisez mes articles).

Heureusement, y’a un outil qui vient de sortir et qui va vous changer la vie : CM-Colors . Vous lui donnez vos couleurs, et il les ajuste automatiquement pour qu’elles soient accessibles, le tout en modifiant les teintes le moins possible pour garder votre design intact.

L’installation est super fastoche…. C’est du Python donc un petit pip install cm-colors et hop c’est réglé. Ensuite, vous pouvez l’utiliser soit en ligne de commande directement sur vos fichiers CSS, soit via l’API dans votre code. Par exemple, vous avez un gris #5f7887 sur un fond #e6f0f5 qui passe pas les tests, hop, CM-Colors le transforme automatiquement en #5c6f7b et maintenant c’est conforme AA. Et la différence à l’œil nu est quasi invisible. Bref, c’est nickel pour l’accessibilité !

from cm_colors import ColorPair

# Your colors
pair = ColorPair("#999999", "#ffffff")

# Fix them and preview in the terminal
fixed_color, success = pair.make_readable(show=True)

print(f"Use {fixed_color} instead of #999999")
# Output: Use #8e8e8e instead of #999999

Le truc vraiment cool, c’est que l’outil gère plusieurs niveaux de lisibilité. Y’a “Readable” qui correspond au AA, “Very Readable” pour le AAA, et même une option large_text=True pour les gros titres qui ont des exigences moins strictes. Vous pouvez donc adapter selon vos besoins et pour les devs qui bossent sur de gros projets, y’a aussi une fonction make_readable_bulk qui permet de corriger plusieurs paires de couleurs d’un coup.

from cm_colors import make_readable_bulk

my_colors = [
 ("#777", "#fff"),
 ("#888", "#000"),
]

results = make_readable_bulk(my_colors)

for color, status in results:
 print(f"{color} is {status}")

Vous lui balancez une liste de tuples (texte, fond) et il vous retourne tout ça au propre. Et si vous voulez traiter directement vos fichiers CSS, la commande cm-colors styles.css génère un nouveau fichier styles_cm.css avec toutes les couleurs corrigées. L’outil peut même générer des rapports HTML pour visualiser les changements avant/après.

Alors oui, je sais, se taper de l’accessibilité c’est un peu relou car on a toujours l’impression que c’est du temps perdu sur des détails. Mais dites vous que ça impacte vraiment l’expérience de millions d’utilisateurs, donc ça vaut le coup d’y passer 5 minutes, surtout avec un outil automatisé !

Bref, CM-Colors c’est gratuit, c’est open source sous licence GPL-3, et ça peut vous éviter pas mal de galères. Toute la documentation est ici et y’a même une démo interactive sur leur site si vous voulez tester avant d’installer.

Si vous avez déjà essayé de générer du pixel art avec une IA comme Midjourney ou le nouveau modèle Nano Banana Pro de Google, vous avez forcément remarqué ce problème : c’est moche de ouf ! Enfin non, c’est pas moche dans l’absolu, mais les pixels sont tout sauf alignés sur une grille propre. On se retrouve avec des trucs qui ressemblent à du pixel art de loin, mais qui sont en fait une bouillabaisse de pixels de tailles variables, mal placés, avec des anti-aliasing qui n’ont rien à faire là.

Heureusement pour nous, Pixel Snapper va nous aider à corriger tout ça en quelques secondes !

L’outil est développé par Hugo-Dz sur GitHub dans le cadre du projet Sprite Fusion. Vous balancez votre image de pixel art foireuse, et il recale automatiquement chaque pixel sur une grille propre comme ça, fini les pixels qui font du 1,3 × 0,8 au lieu de faire un beau carré 1 × 1 comme le bon dieu du rétro gaming l’a voulu.

Voici la différence… A gauche c’est l’image IA, et à droite, c’est l’image recalée comme il faut :

Le truc cool, c’est que l’outil préserve tous les détails de votre image, c’est à dire le dithering, les courbes, les petits trucs subtils que vous ne voulez pas perdre dans la conversion. C’est pas un outil qui va vous massacrer l’image en la pixelisant bêtement même si certaines couleurs sautent car faut pas dépasser les 16 couleurs.

Voilà, il analyse la structure et recale intelligemment chaque élément sur la grille cible en moins de 2 secondes. Y’a pas besoin de vous créer un compte et c’est sans limite.

En plus, c’est gratuit et open source, donc vous pouvez l’utiliser pour vos projets perso comme pour vos jeux commerciaux sans vous poser de questions. D’ailleurs si vous bossez avec Unity, Godot, Defold ou Flame, les assets générés sont directement utilisables dans vos projets.

Voilà, si vous utilisez des générateurs d’images IA pour créer des assets de jeux rétro et que vous en avez marre de passer des heures à recaler les pixels à la main, testez Pixel Snapper !

Si vous bidouiller un peu de machine learning et que vous avez la flemme de coder une interface web from scratch pour montrer vos jolis modèles, vous connaissez probablement Gradio , cette librairie Python qui permet de créer des démos interactives en quelques lignes de code.

Hé bien, excellente nouvelle, la version 6 vient de sortir et elle apporte pas mal de nouveautés intéressantes.

La grosse news de cette mise à jour , c’est d’abord la refonte complète de l’architecture avec le passage à Svelte 5 . Pour ceux qui s’en fichent du frontend, ça veut dire concrètement que vos apps seront plus légères et plus rapides à charger. L’équipe a aussi bossé sur l’optimisation des files d’attentes (quand y’a du monde sur votre démo), surtout pour les serveurs MCP (Model Context Protocol), donc si vous hébergez des trucs sur Hugging Face Spaces, vous devriez sentir la différence.

Côté fonctionnalités, y’a aussi quelques ajouts sympas comme le support natif des sous-titres pour les vidéos et l’audio, une nouvelle interface “MultimodalTextbox” améliorée pour le mobile (qui était franchement pas terrible avant), et pour ceux qui font des apps multipages, y’a maintenant un composant “Navbar” dédié à ça !

Le truc qui va plaire aux devs aussi, c’est qu’on peut désormais écrire des composants web personnalisés directement en HTML/JavaScript inline dans le code Python. Comme ça, plus besoin de sortir l’artillerie lourde avec des outils de build externes. Vous collez juste votre HTML, votre JS, et c’est parti mon kiki.

Par contre, attention si vous avez des projets existants… Y’a des changements qui vont casser des trucs. Par exemple, le format tuple dans le Chatbot a été supprimé, le composant Sketch est déprécié, et pas mal de paramètres ont bougé dans les composants graphiques natifs. L’équipe a quand même prévu un guide de migration avec des warnings de dépréciation pour vous aider à faire la transition.

A partir de maintenant, seule la branche 6.x sera maintenue, donc si vous êtes encore sur une vieille version, c’est le moment de migrer. La mise à jour se fait classiquement avec un

pip install --upgrade gradio

Notez que Gradio 6 nécessite Python 3.10 minimum et le support de Python 3.14 a été ajouté pour vous, les early adopters ^^.

Voilà, si vous faites du ML ou autre et que vous voulez montrer vos démos sans vous prendre la tête avec du React ou du Vue, Gradio reste une valeur sûre, et avec cette version 6 qui arrive, ce sera encore plus fluide et rapide !

Source