Échec de compilation : trouvez la ligne qui compte, puis corrigez la cause.

• Trouvez l’étape. Un déploiement installe les dépendances, compile, exécute la commande de mise en production s’il y en a une, puis démarre l’appli. Sur Canner, le résumé nomme l’étape : install failed (exit 1) ou build failed (exit 1), suivi des lignes d’erreur retenues.
• Ignorez les avertissements. Les lignes npm warn deprecated … et les avertissements de taille de paquet ne font pas échouer une compilation. Le résumé de Canner écarte les lignes marquées comme avertissements pour cette raison.
• Remontez depuis la fin. Les dernières lignes sont d’habitude l’outil qui annonce sa sortie. La cause est la première ligne Error:, npm error, ✘ [ERROR] ou Type error: au-dessus.
• Notez le code de sortie. Il indique si l’outil a échoué de lui-même ou s’il a été arrêté de l’extérieur (tableau ci-dessous).

Voici les messages qu’affiche Canner et ceux des outils qu’il reconnaît. Sur un déploiement en échec, Canner affiche une fiche Comment corriger pour la cause trouvée, avec le journal brut à un clic sous Détails de l’erreur.

Canner installe les dépendances avec les scripts d’installation désactivés, par prudence face à la chaîne d’approvisionnement. La plupart des paquets n’en ont pas besoin. Ceux qui compilent ou téléchargent un binaire natif (sharp, bcrypt, better-sqlite3, canvas) s’installent sans erreur, puis échouent au premier import, parfois à l’exécution plutôt qu’à la compilation.

Le journal de compilation vous avertit avant, en nommant les paquets. Autorisez-les dans package.json; Canner recompile alors ceux-là seulement, sans accès au réseau :

// package.json: let these packages run their install script
{
  "canner": { "allowedBuildScripts": ["sharp", "better-sqlite3"] }
}

// pnpm projects can use pnpm's own setting instead
{
  "pnpm": { "onlyBuiltDependencies": ["sharp", "better-sqlite3"] }
}

Un déploiement s’exécute sans surveillance. Quand une commande affiche quelque chose comme Would you like to proceed? (y/N) puis se tait environ 20 secondes, Canner considère qu’elle attend une réponse. Pour la commande de mise en production, la page du déploiement affiche la question et, si les réponses sont activées, propose Oui et Non; sans personne, elle s’arrête après 5 minutes en indiquant la question posée. La documentation des déploiements liste les options habituelles : --force pour prisma migrate reset et artisan migrate, --accept-data-loss pour prisma db push, --noinput pour collectstatic de Django.

Une compilation réussie doit encore démarrer. La nouvelle version doit répondre sur / (ou votre chemin de vérification d’état) en 30 secondes. app did not respond on / within 30s veut presque toujours dire que l’appli écoute sur un port codé en dur au lieu de process.env.PORT, ou qu’elle a planté au démarrage faute d’une variable. Le message d’échec inclut la fin du journal de votre appli, où se trouve d’habitude la trace. Un robot ou un exécuteur de tâches sans serveur Web doit être redéployé comme processus de fond (worker), ce qui saute la vérification. La documentation de dépannage couvre chaque cas.

Une commande de mise en production en échec arrête le déploiement avant le démarrage de la nouvelle version : la version en ligne continue de tourner.

Les compilations qui « marchent sur mon poste » diffèrent presque toujours d’une de quatre façons : des fichiers non versionnés, un fichier de verrouillage pas à jour, un système de fichiers insensible à la casse ou une autre version de Node. Un conteneur Linux propre les écarte toutes :

# Reproduce a clean Linux build on your machine
docker run --rm -it -v "$PWD":/app -w /app node:22 \
  sh -c "npm ci && NODE_ENV=production npm run build"

Si vous travaillez avec Claude Code ou Cursor, le serveur MCP de Canner donne à l’agent l’outil canner_get_deployment, qui renvoie un déploiement au complet, journal de compilation inclus. Il peut lire l’échec, corriger le code et redéployer sans que vous copiiez de journaux. D’autres guides sont dans hébergement par cadriciel.