Tu as construit une petite application avec GitHub Spark, puis tu l’as laissée dormir dans ton compte ? Réveille-la avant le 31 août 2026. GitHub arrête son atelier d’applications créé en langage naturel : les nouveaux utilisateurs sont déjà bloqués depuis le 4 août, et les utilisateurs actuels ont quelques semaines pour exporter leurs projets. L’arrêt ne casse pas les applications déjà déployées, mais il coupe la possibilité de les modifier dans Spark.
Spark permettait de décrire une idée, de voir une interface fonctionner immédiatement et de publier une mini-application sans installer une chaîne complète d’outils. C’était pratique pour un prototype, un outil interne ou une page interactive. La fermeture rappelle toutefois le piège des plateformes intégrées : tant que le service existe, tout paraît simple ; quand il disparaît, le bouton d’export devient soudain le bouton le plus important de l’écran.
Ce qui ferme exactement
GitHub indique que Spark n’accepte plus de nouveaux utilisateurs ni de nouvelles applications depuis le 4 août. L’accès aux applications existantes reste ouvert jusqu’au 31 août, afin de laisser le temps de récupérer leur code. Après cette date, les applications déjà déployées doivent continuer à fonctionner, mais Spark sera retiré comme environnement de création et de modification sur github.com.
Il faut distinguer deux changements. La plateforme Spark disparaît, et GitHub Models, le service d’inférence utilisé par la fonction llm(), a déjà été retiré le 30 juillet. Une application Spark sans llm() devrait continuer à fonctionner après la fermeture ; une application qui appelle cette fonction perd ses réponses IA, sauf si tu remplaces le fournisseur d’inférence par un service séparé et que tu gères toi-même la clé ainsi que la facturation.
Visuel : illustration officielle de l’annonce GitHub. Source : GitHub Changelog, https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/
La marche à suivre pour ne rien perdre
Ouvre chaque application dans l’atelier Spark avant la date limite, puis utilise le menu « … » et l’option « Create repository ». GitHub crée alors un dépôt avec le code de l’application. Recommence pour chaque projet auquel tu tiens : l’export n’est pas une sauvegarde globale magique qui rangerait tout ton compte dans un joli fichier zip.
Une fois le dépôt créé, clone-le ou télécharge une archive et vérifie son contenu. Cherche notamment les appels à llm(), les variables d’environnement, les secrets et les dépendances nécessaires au fonctionnement. Ne commite jamais une clé API trouvée dans un fichier de configuration : remplace-la, crée un secret dans le nouvel hébergement et considère toute clé déjà exposée comme compromise.
Le cas pénible des fonctions IA
Si ton application n’utilise pas llm(), le retrait de GitHub Models ne devrait pas la toucher. Si elle l’utilise, le code exporté ne récupérera pas par magie le modèle qui répondait auparavant. Il faudra choisir un autre fournisseur d’inférence, adapter l’appel et stocker ta propre clé. Le résultat peut changer, la facture aussi, et la protection des données dépendra désormais des conditions du nouveau service.
Cette migration est l’occasion de tester l’application avec des données fictives. Vérifie les erreurs quand le modèle est indisponible, limite les permissions du jeton et affiche clairement à l’utilisateur ce qui part vers le fournisseur choisi. Une mini-app qui répond joliment avec des données de démonstration est facile à migrer ; une mini-app qui contient des données personnelles dans une fonction opaque demande un vrai audit.
Quelle alternative après Spark ?
Pour un prototype simple, le dépôt exporté peut repartir vers un hébergement web classique, un service de déploiement lié à Git ou une machine que tu contrôles. Le choix dépend du niveau de confort recherché : l’objectif n’est pas de remplacer un bouton par quinze fichiers de configuration, mais de retrouver une chaîne que tu peux comprendre et sauvegarder.
GitHub présente Copilot dans VS Code, Copilot CLI et l’application Copilot comme les environnements vers lesquels il veut déplacer la construction assistée. C’est cohérent pour les personnes déjà dans cet écosystème, moins pour celles qui avaient choisi Spark précisément pour éviter l’environnement de développement. Le message pratique reste le même : exporte d’abord, décide ensuite si tu veux rester chez GitHub.
Ne confonds pas simplicité et propriété
Spark avait rendu visible une tendance utile : une idée peut devenir une application testable sans passer par une installation interminable. Mais l’hébergement, la base de données, l’inférence et le déploiement étaient intégrés dans une offre qui pouvait changer de direction. Le code exporté te redonne une porte de sortie, à condition d’avoir pensé à la pousser avant que la porte ne se ferme.
Si tu n’as jamais utilisé Spark, il n’y a rien à migrer. Si tu as une application active, fais l’inventaire aujourd’hui : projets, dépôts, domaines, appels à llm(), secrets et données. Le 31 août n’est pas une date de fin du Web ; c’est simplement la date à laquelle GitHub cessera de faire semblant que ton atelier sera encore là demain.
Sources
GitHub Changelog, annonce officielle du retrait de GitHub Spark et procédure d’export, publiée le 4 août 2026 : https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/
GitHub Changelog, retrait de GitHub Models et de son service d’inférence, effectif le 30 juillet 2026 : https://github.blog/changelog/2026-07-30-github-models-is-now-retired/
GitHub, présentation et usages de Spark avant son retrait : https://github.com/features/spark
Hacker News, reprise de l’annonce officielle et discussion datée du 6 août 2026 : https://news.ycombinator.com/item?id=49194979
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet