Claude Code a abîmé votre devoir Swift ? Guide de récupération pour débutants 2026

Le devoir Swift ne compile plus, un fichier a changé ou le résultat affiché dans Xcode est différent.

Solution la plus sûre : arrêtez les modifications de Claude Code, copiez le projet, examinez les différences, restaurez seulement ce qui est nécessaire, puis vérifiez le résultat dans Xcode. Sans sauvegarde, ou si l’origine d’un fichier est incertaine, ne le remplacez pas et ne le supprimez pas.

Ce guide s’adresse aux étudiants qui débutent en Swift ou en développement iOS et utilisent Claude Code pour comprendre ou modifier un exercice. Il aide à repérer le problème avant de toucher au projet de cours.

Identifier le symptôme avant de restaurer

Un projet qui semble « cassé » peut présenter des problèmes différents. Distinguer le symptôme évite de remplacer des fichiers sans savoir si cela répond à la cause.

• Le contenu d’un fichier ne ressemble plus au cours. Une fonction, un commentaire ou une structure a changé. Le projet peut encore compiler, mais la modification doit être comparée au travail attendu.
• La compilation échoue. Xcode affiche une erreur. Elle peut venir du code, d’un réglage du projet ou d’une incompatibilité avec l’environnement ; elle ne prouve pas à elle seule qu’un fichier a été détruit.
• L’application se lance, mais son comportement a changé. L’écran, le son, la navigation ou le résultat d’un calcul ne correspond plus à l’exercice. Notez précisément ce qui diffère.
• Le code est devenu difficile à comprendre. Le projet fonctionne peut-être, mais une modification que l’étudiant ne sait pas expliquer peut ne pas convenir au devoir ou à ses règles d’évaluation.

Avant toute autre action, consignez le texte intégral de l’erreur, le nom du fichier concerné et ce qui se passe à l’exécution. Si le problème concerne un projet créatif, notez aussi ce qui a changé dans l’interface, l’aperçu vidéo ou la sortie audio. Ces observations donnent un point de comparaison sans ajouter de nouvelles modifications.

Choisir la méthode selon l’historique disponible

La bonne méthode dépend surtout de l’existence d’une copie fiable ou d’un historique Git. Les options ci-dessous ne promettent pas une récupération automatique : elles indiquent quoi examiner avant d’agir.

Une copie indépendante est utile même si le projet est déjà suivi par Git. Les fichiers non enregistrés dans l’historique peuvent être importants, et une commande mal choisie peut retirer des changements que l’étudiant souhaitait conserver.

Changements de fichiers inconnus

Lorsqu’il n’est pas évident de savoir ce que Claude Code a modifié, ne commencez pas par supprimer les fichiers qui semblent nouveaux. Repérez d’abord leur état et leur contenu.

Dans le dossier du projet, la commande suivante affiche les fichiers modifiés, ceux préparés pour validation et ceux que Git ne suit pas encore :

git status --short

La documentation de git status décrit les catégories présentées par cette commande. Un fichier signalé comme non suivi n’est pas automatiquement superflu : il peut s’agir d’un fichier demandé par le cours, d’une ressource utile ou d’un nouveau fichier créé pendant le travail.

Pour examiner les changements apportés aux fichiers suivis, lancez :

git diff

La commande git diff présente les différences entre l’état de travail et l’index. Cette comparaison permet de voir les lignes ajoutées ou retirées, plutôt que d’inférer le contenu à partir du seul nom du fichier. Si rien ne s’affiche, cela ne signifie pas nécessairement qu’aucun fichier n’a changé : les nouveaux fichiers non suivis ne sont pas montrés de la même manière. Vérifiez alors la liste de git status et comparez les dossiers concernés.

Examinez les résultats fichier par fichier. Une modification dans un fichier de configuration peut affecter la compilation sans toucher au code Swift ; une modification dans une vue peut changer l’écran tout en laissant le projet se construire. Les fichiers du cours et les ressources nécessaires doivent rester dans le dossier, sauf si leur rôle et leur remplacement ont été confirmés.

Claude Code dispose de fonctions d’utilisation en ligne de commande et de réglages liés aux autorisations. La documentation de son interface en ligne de commande et son guide de démarrage peuvent aider à comprendre comment l’outil est utilisé. Ces pages ne déterminent toutefois pas si une modification est acceptable pour un devoir : cette vérification revient à l’étudiant, en fonction des consignes.

Projet sans historique Git

Sans Git, il n’existe pas de commande permettant de comparer automatiquement le projet actuel à une version enregistrée. Il faut donc préserver ce qui existe, puis chercher une référence fiable.

Commencez par dupliquer le dossier entier, pas uniquement le fichier qui semble suspect. Donnez à la copie un nom qui la distingue clairement et ouvrez ensuite la copie de travail plutôt que l’original. Cela permet de revenir à l’état constaté si une tentative de remplacement aggrave le problème.

Cherchez une version antérieure dans les documents du cours, une archive originale, un dossier de remise ou une sauvegarde personnelle. Comparez le fichier suspect avec cette référence. Si le fichier provient d’une ressource de cours confirmée et qu’il a été modifié, son contenu original peut servir de point de départ ; les changements personnels doivent cependant être conservés ailleurs avant le remplacement.

Si l’étudiant ne peut pas établir la provenance d’un fichier, il doit le garder. Cette précaution concerne notamment les fichiers dont le rôle n’est pas évident ou ceux dont le contenu n’a pas été étudié en classe. Le nom seul ne suffit pas pour décider qu’un fichier peut être supprimé.

Pour limiter les confusions, notez dans un fichier séparé les éléments restaurés et leur source, par exemple « fichier récupéré depuis l’archive du cours ». Cette trace aide ensuite à expliquer le travail et à distinguer les éléments fournis des modifications personnelles. Si les documents de cours ne contiennent pas de version de référence, mieux vaut demander conseil à l’enseignant plutôt que de remplacer des éléments au hasard.

Historique Git et restauration ciblée

Git permet d’examiner l’état du projet et de revenir sur des changements, mais une restauration peut faire perdre du travail. Il faut d’abord vérifier la copie de sauvegarde et la portée exacte de la commande.

Pour consulter les changements enregistrés dans l’historique, utilisez :

git log --oneline

La documentation de git log explique comment afficher les enregistrements du dépôt. Repérez une version que vous connaissez et qui précède le problème ; ne choisissez pas une entrée uniquement parce qu’elle est la plus récente.

Pour restaurer un seul fichier depuis la version actuelle de l’index vers le dossier de travail, la forme ciblée est :

git restore --worktree -- chemin/du/fichier.swift

La commande officielle git restore permet également d’indiquer une autre source. Avant de l’exécuter, vérifiez que le chemin désigne bien le fichier voulu : cette opération remplace son état de travail et peut écraser des modifications présentes dans ce fichier.

Si le contenu à récupérer vient d’un enregistrement antérieur, la commande peut préciser sa source, par exemple :

git restore --source=identifiant-de-validation --worktree -- chemin/du/fichier.swift

L’identifiant doit correspondre à une version déjà repérée dans l’historique. Cette commande ne doit pas être lancée à l’aveugle sur tout le projet : restaurez les seuls fichiers nécessaires, puis comparez de nouveau leur contenu.

Les changements préparés pour validation demandent une attention particulière. git restore --staged -- chemin/du/fichier.swift retire le fichier de la zone de préparation, mais ne constitue pas la même action que la restauration du contenu dans le dossier de travail. Lisez la documentation de git restore, contrôlez git status avant et après, et ne confondez pas le retrait de la préparation avec l’annulation d’une modification.

Un changement déjà enregistré dans l’historique n’est pas équivalent à une modification encore présente uniquement dans le dossier de travail. Pour retrouver un contenu antérieur, identifiez d’abord la bonne version, restaurez un fichier précis dans une copie du projet, puis examinez le résultat. Les commandes de restauration n’attestent pas que le code retrouvé respecte les consignes du cours.

Compilation, exécution et conformité au devoir

Après une restauration, ouvrez le projet dans Xcode et vérifiez séparément la compilation, le lancement et le comportement demandé. Pour un devoir d’interface, contrôlez l’écran et la navigation ; pour un projet audio ou vidéo, vérifiez les ressources et le rendu attendu. Un projet qui compile peut encore produire un résultat différent de celui exigé.

Les consignes d’évaluation restent la référence. Comparez le résultat aux fonctionnalités, à la structure des fichiers et aux règles de remise indiquées par l’enseignant. Si une modification est difficile à expliquer, l’étudiant doit la relire, la tester et demander de l’aide avant de la remettre. Une explication produite par Claude Code ne prouve ni que le code est juste ni qu’il répond aux critères de notation.

Quand Xcode échoue à construire le projet, conservez l’erreur complète et identifiez le fichier ou l’étape mentionnés. Apple documente les projets et la compilation dans sa documentation Xcode. Certains échecs dépendent des phases de construction ou de la configuration du projet ; la page Apple sur la personnalisation des phases de construction d’une cible aide à vérifier cette piste au lieu de modifier le code au hasard.

Vérifiez aussi que la version de Xcode demandée par le cours est compatible avec le Mac et le système utilisés. La page Apple consacrée aux versions de Xcode et à leur configuration système est la référence pour ces exigences, qui varient selon la version. Si les consignes mentionnent Xcode 27, vérifiez directement la version et les exigences indiquées par Apple ; ne supposez pas qu’un projet exige cette version simplement parce qu’elle apparaît dans une recherche.

Une fois le projet construit, testez les fonctions demandées par le devoir et relisez le diff. Vérifiez que la restauration n’a pas retiré une ressource utile, que le comportement attendu est revenu et que les fichiers remis sont bien ceux prévus par le cours. Si le projet échoue encore, partagez le message exact avec l’enseignant ou le service d’aide, en précisant les changements déjà examinés.

Questions fréquentes

Un projet Swift ne se lance plus après une modification de Claude Code

Arrêtez les nouvelles modifications et copiez le dossier du projet dans un autre emplacement. Notez le message d’erreur complet, puis comparez l’état actuel avec la dernière version connue. Vérifiez ensuite si le problème touche le code, les réglages de compilation ou l’environnement Xcode ; une restauration complète n’est pas toujours nécessaire.

Retrouver un fichier de cours modifié sans sauvegarde Git

Conservez d’abord une copie intacte du dossier actuel. Cherchez ensuite la version originale dans les fichiers fournis par le cours, une archive téléchargée ou une sauvegarde personnelle, puis comparez le contenu avant de remplacer quoi que ce soit. Si l’origine d’un fichier reste incertaine, gardez-le : son nom seul ne permet pas de savoir s’il est supprimable.

Repérer les changements effectués dans un projet Swift

Si le projet utilise Git, commencez par afficher son état, puis examinez les différences avant de choisir une restauration. Cette vérification permet de distinguer les fichiers suivis qui ont été modifiés, les changements préparés pour validation et les nouveaux fichiers non suivis. Sans Git, comparez les dossiers avec une copie fiable ou les fichiers d’origine du cours.

Récupérer un devoir sans historique Git

Il est parfois possible de retrouver les fichiers d’origine dans les ressources du cours, une archive ou une copie antérieure, mais aucune méthode ne garantit une récupération complète. Travaillez sur une copie, remplacez uniquement les éléments dont la provenance est vérifiée et gardez les fichiers ambigus. Vérifiez ensuite la compilation et les exigences du devoir dans Xcode.

Quand un Mac devient nécessaire

Pour une vérification complète dans Xcode, l’étudiant a besoin d’un environnement compatible avec les exigences du projet et du cours. Si aucun Mac n’est disponible, il peut d’abord vérifier si l’établissement autorise un poste de laboratoire ou un autre environnement géré. Le guide pour bien démarrer avec un Mac à distance présente les étapes à examiner avant de choisir cette solution.

Il est également utile de comparer les options selon la durée du devoir et les besoins réels. Un ordinateur déjà disponible ou l’accès autorisé à un poste scolaire peut suffire ; pour un besoin ponctuel, la location évite l’achat immédiat, mais dépend d’une connexion et d’un accès distant. La page de comparaison des solutions Mac aide à mettre ces choix en regard.

Choisir un environnement de vérification adapté

Le projet doit rester sauvegardé avant toute nouvelle tentative. Si le devoir exige réellement macOS et Xcode, mais qu’aucun Mac personnel ou poste scolaire n’est accessible, un Mac distant peut servir à ouvrir le projet, compiler et vérifier le résultat. Cette option ne remplace ni la compréhension du code ni les règles de l’établissement ; elle ajoute aussi une dépendance à la connexion et à l’accès distant.

À l’inverse, acheter un Mac n’est pas forcément raisonnable pour un exercice ponctuel, et un environnement non autorisé par l’établissement ne convient pas si le devoir impose des conditions particulières. Après avoir contrôlé ces contraintes, les étudiants qui ont seulement besoin d’un environnement temporaire peuvent consulter les offres de location Mac de NUMACS, puis décider si cet accès répond effectivement à leur cours.

Questions fréquentes