Par Thomas Cohen, fondateur de Maestro
Firebase Studio et GitHub Spark : préparer la reprise de votre application
La fermeture de Firebase Studio ne signifie pas la fin de Firebase. Voici les échéances officielles, le cas distinct de Spark et une méthode pour retrouver le code, les données et les accès avant de changer d’outil.
Votre application s’ouvre encore, mais son outil de création annonce sa fermeture. La première question est pratique : pourrez-vous corriger un problème, retrouver vos données et publier une modification demain ? Avant de choisir un nouvel assistant IA, rassemblez les éléments qui permettront à une autre personne de comprendre et de reprendre le projet.
Nous suivrons Camille, qui organise des ateliers, et Noé, qui l’aide à préparer la reprise d’un outil de réservation. Leur application, leurs dossiers et les vérifications racontées sont fictifs. Ce guide associe des annonces officielles vérifiées le 26 septembre 2026 à une méthode de préparation ; il ne présente pas une migration que nous aurions réalisée chez un client.
1. Firebase Studio : ce qui ferme, et ce qui reste
Les nouvelles inscriptions et créations d’espaces sont bloquées depuis le 22 juin 2026. Les espaces existants ferment le 22 mars 2027. Firestore, Authentication et App Hosting restent disponibles : c’est l’environnement Studio qui s’arrête. Voir le calendrier officiel.
Si vous voyez « New user registration for Firebase Studio is currently closed », commencez donc par identifier votre situation : cherchiez-vous à créer un compte ou à accéder à un espace existant ? Conservez le message exact, le compte utilisé et l’adresse de l’espace. Ces informations seront plus utiles au support qu’un simple « Firebase ne marche plus ».
Google explique regrouper ses outils de création IA autour d’AI Studio et d’Antigravity. Les données restant dans l’espace Studio seront supprimées à sa fermeture. Le guide officiel de migration détaille cette décision. Elle ne permet pas de conclure que votre idée d’application ou son fonctionnement métier étaient mauvais.
2. GitHub Spark : partir de ce que vous avez déjà conservé
GitHub a retiré Spark le 31 août 2026. Son annonce maintient les applications déjà publiées, mais fixait l’export du code avant cette date via « Create repository ». Les appels llm() doivent être remplacés. Le service correspondant, GitHub Models, s’est arrêté le 30 juillet.
Cherchez d’abord un dépôt ou une archive déjà créés. Demandez à la personne qui a construit l’application où se trouve la dernière version conservée. Si vous ne retrouvez rien, faites préciser les possibilités restantes par le support. Ne confondez pas une application visible avec un dossier source récupérable ; nous ne garantissons ici aucune récupération après l’échéance.
Si une fonction IA ne répond plus, décrivez laquelle : rédiger un message, classer une demande ou résumer un texte. Demandez à Noé de vérifier son service et les accès nécessaires à son remplacement. Relancer toute la construction avant d’avoir isolé la panne peut faire perdre du temps et introduire de nouvelles erreurs.
3. Faire l’inventaire de six éléments distincts
Camille connaît l’adresse de son application et possède quelques captures. Cela aide à expliquer son fonctionnement, mais ne permet pas encore de la remettre en service ailleurs. Avec Noé, elle prépare une fiche par élément. Chaque fiche porte un emplacement, une personne responsable, la dernière vérification et ce qui manque.
- Code : fichiers qui décrivent les écrans et le fonctionnement, avec la version à reprendre.
- Données : réservations, coordonnées et documents réellement enregistrés.
- Comptes : service de connexion et personnes capables d’administrer le projet.
- Configuration : adresses des services et accès confidentiels dont l’application dépend.
- Publication : hébergement, adresse publique et contrôle du nom de domaine.
- Dépenses : abonnements actifs, consommation et personne qui reçoit les factures.
Un même compte peut contrôler plusieurs éléments ; cela ne les rend pas interchangeables. Camille peut payer un abonnement sans disposer de l’accès permettant de modifier l’application. Noé peut avoir le code sans pouvoir consulter les réservations. Notez ces différences avant de lancer une copie ou de fermer un service.
4. Récupérer le code et vérifier ce qui a été obtenu
Dans Firebase Studio, le chemin indiqué par Google est « Move now », puis « Zip and Download ». Le guide de migration décrit les options selon votre projet. Si l’espace vous a été partagé, faites préciser la méthode d’export avec son propriétaire. Conservez la date de l’export et faites ouvrir l’archive obtenue : une fin de téléchargement n’est pas encore une vérification de son contenu.
Noé doit pouvoir reconnaître la version attendue, retrouver la dernière modification de l’écran de réservation et expliquer comment lancer une copie. Camille conserve séparément une description du parcours et les décisions importantes. Si la personne qui reprend le projet doit deviner toutes les règles dans une ancienne conversation, le dossier reste incomplet.
Travaillez sur une copie. Demandez que les fichiers d’origine restent conservés et que les modifications soient identifiables. Si le projet ne démarre pas, notez le message exact et l’étape qui bloque. « Remplacer les fichiers jusqu’à ce que cela fonctionne » ne produit pas une procédure que vous pourrez refaire.
5. Vérifier les données et les comptes séparément
L’archive du code n’est pas la preuve que les réservations ont été sauvegardées. Faites identifier l’endroit où elles sont stockées, les pièces jointes éventuelles et la méthode de récupération adaptée. Demandez une vérification sur des exemples préparés pour l’essai. Évitez de remettre de vraies coordonnées à un nouvel assistant simplement pour voir s’il comprend le projet.
Dans notre scénario, Camille choisit trois cas fictifs : une réservation confirmée, une demande annulée et deux personnes portant le même nom. Pour chacun, elle note le résultat attendu. Noé doit retrouver le bon dossier, son état et son document. Compter trois lignes ne suffit pas si les dossiers ont été mélangés.
Traitez aussi la connexion comme un sujet distinct. Une liste de clients ne contient pas nécessairement ce qui permet aux utilisateurs de se connecter. Faites vérifier les comptes existants, l’ajout d’un nouveau compte, la récupération d’accès et les permissions. Changer l’interface sans avoir testé ces parcours peut laisser les utilisateurs devant une porte fermée.
Le guide de migration des données aide à préparer une correspondance et un rapport d’essai. Si les données restent dans le même service, écrivez-le : déplacer l’outil de développement n’oblige pas à déplacer toutes les informations. Cette décision doit être confirmée sur votre projet réel.
6. Retrouver les accès, le domaine et les dépenses
Noé inventorie les services nécessaires sans recopier leurs secrets dans une fiche publique. Une clé donnant accès à un service doit être gérée dans l’emplacement prévu pour elle, avec une personne capable de la remplacer. Demandez quels accès seront nécessaires dans le nouvel environnement et comment limiter leur portée. Une valeur trouvée dans une archive n’est pas une invitation à la diffuser.
Camille vérifie qui contrôle le nom de domaine et l’hébergement. Elle demande ce qui changera pour le visiteur : adresse, connexion, emails reçus ou liens déjà partagés. Avant de déplacer l’adresse publique, faites examiner les réglages dépendants. Un écran accessible à une adresse de test ne prouve pas que les confirmations arriveront aux clients.
Côté dépenses, listez les services encore payants et leur utilité. Qui suit la consommation du nouveau fournisseur IA ? Quel abonnement peut rester nécessaire pendant l’essai ? À quelle condition arrêter l’ancien ? Attendez une vérification avant de supprimer un service qui pourrait encore porter des données ou faire fonctionner l’application.
7. Choisir un chemin de reprise que quelqu’un peut entretenir
Camille compare les possibilités sur une modification limitée : ajouter un champ facultatif à une demande, conserver les anciennes réservations et publier la correction dans un environnement d’essai. Elle observe ce que Noé doit installer, expliquer ou corriger. Ce travail donne une base plus utile que le nombre d’outils proposés sur une page de comparaison.
Le choix doit préciser où le code sera conservé, qui pourra le modifier et comment une nouvelle version sera publiée. Demandez aussi ce que la personne suivante devra savoir pour prendre le relais. Si tout dépend d’un compte personnel inaccessible ou d’une manipulation que personne n’a notée, la reprise reste fragile.
Un devis utile sépare l’état des lieux, les adaptations, la récupération des données, les essais et la mise en service. Il identifie les inconnues avant de promettre un prix total. La propriété et la reprise du projet concernent autant les droits et les accès que les fichiers copiés.
8. Faire un essai complet avec des résultats attendus
Préparez un environnement où les essais n’enverront pas de messages aux vrais clients et ne modifieront pas les réservations utilisées au quotidien. Camille et Noé indiquent les données fictives à utiliser et ce qui doit être coupé ou remplacé pour l’essai. Faites confirmer cette séparation avant le premier clic.
- Une personne autorisée se connecte et retrouve uniquement les dossiers prévus pour elle.
- Une nouvelle réservation conserve sa date et son état après fermeture puis réouverture.
- Une annulation libère la bonne place sans effacer les autres réservations.
- Une pièce jointe s’ouvre sur le bon dossier et reste inaccessible au compte non autorisé.
- Une fonction IA produit un résultat vérifiable ; son échec donne un message compréhensible.
- Une modification du code peut être publiée à nouveau depuis le dossier transmis.
Pour chaque essai, notez la date, la personne, le résultat attendu, le résultat observé et la preuve conservée. Dans notre exemple, une confirmation visible ne vaut pas réception de l’email. Camille vérifie aussi la boîte de test. Une réponse rassurante de l’agent ne remplace pas cette observation.
Après une correction, refaites les contrôles concernés et un parcours complet. Si la connexion fonctionne seulement avec le compte de Noé, le travail n’est pas terminé pour Camille. Faites relire les aspects techniques et les autorisations par une personne compétente ; les essais métier ne couvrent pas tous les risques.
9. Préparer le changement et un retour possible
Décidez quel système fait référence pendant la transition. Si l’ancienne application reçoit encore des réservations, expliquez comment elles seront retrouvées après le changement. Une copie faite lundi ne contient pas automatiquement les demandes du mardi. Désignez la personne qui rapproche les nouvelles écritures avant de donner le feu vert.
Le plan de retour doit préciser la version à remettre en service, les données à conserver et les actions nécessaires. Faites répéter la procédure sur une copie. Revenir à un ancien code ne restaure pas forcément les nouvelles réservations, et une sauvegarde ancienne peut faire disparaître les modifications récentes si elle est utilisée sans préparation.
Fixez également les raisons d’arrêter : dossiers manquants, accès incorrect, confirmation non reçue ou impossibilité de publier une correction. Prévoyez qui décide et qui peut intervenir. Camille ne bascule pas parce que la date approche ; elle bascule lorsque les conditions convenues sont remplies et que l’équipe sait quoi faire en cas de problème.
10. Terminer avec une décision et des responsables
Faut-il tout reconstruire ? Pas avant d’avoir déterminé ce qui manque. Un accès perdu, une fonction IA à remplacer et un code impossible à relancer sont trois problèmes différents. Faites chiffrer les travaux réellement nécessaires. Si vous ne connaissez pas encore l’état du projet, commencez par un diagnostic limité avec un résultat écrit.
Peut-on continuer avec Maestro ? Nous éditons Maestro, qui aide à diriger la construction ou la reprise par des agents IA depuis un Mac. Il ne garantit pas une migration automatique de Studio ou de Spark. La compatibilité, les données et la publication doivent être examinées et essayées ; aucune capture de démonstration ne constitue une preuve de reprise de votre application.
Les fichiers du projet restent sur votre machine, avec des échanges possibles vers les fournisseurs d’IA, comme l’explique notre page sur les données. La beta est gratuite sur invitation ; l’usage IA et les frais de fonctionnement de votre application restent à prévoir. Choisissez cette voie seulement si quelqu’un peut comprendre et maintenir le résultat.
Avant de conclure, Camille remplit sa fiche : code vérifié, données retrouvées, connexions essayées, publication répétée, dépenses identifiées et retour préparé. Chaque ligne a un responsable et une preuve, ou une question ouverte. C’est ce dossier qui permet de décider de la suite, quel que soit l’outil retenu.