Le projet a été repris
La responsabilité a changé de mains, la documentation est incomplète et la carte réelle des dépendances n’est pas claire.
Analyse & réparation de projets Unity
Des problèmes avec votre projet Unity ? Découvrez ce qu’il faut corriger.
Vous avez repris un projet Unity, perdu votre ancien développeur ou constaté que le jeu ou l’application ne fonctionne plus ? Je vérifie le code source, la façon de démarrer le projet et les appareils concernés, puis explique ce qu’il faut corriger. Vous pouvez utiliser le rapport avec votre équipe ou me confier les réparations convenues.
20–40hPremière évaluation type
Commencer par le buildDes preuves avant les promesses
NDAAvant un accès confidentiel
ConcretCorrection possible
Quand commencer ici
Le projet existe. La confiance manque.
Une analyse est utile lorsque vous devez choisir les corrections ou développements suivants sans disposer encore d’une vision fiable de l’état du projet.
Le build est fragile
Le projet fonctionne sur une machine, échoue en CI ou dépend d’une configuration locale non documentée et d’étapes manuelles.
Les performances bloquent la publication
Temps par image, mémoire, chargement, plantages ou comportements propres à un appareil nécessitent un diagnostic fondé sur des preuves.
Les intégrations cessent régulièrement de fonctionner
Les connexions aux services serveur, outils tiers, fonctions du téléphone, Steam ou appareils VR causent régulièrement des problèmes lors de la préparation d’une mise à jour.
Les changements ont des effets imprévisibles
Des systèmes fortement couplés rendent les petites corrections coûteuses et sujettes aux régressions.
La feuille de route repose sur des suppositions
L’équipe a besoin d’une décision défendable pour terminer, refactoriser ou reconstruire avant d’augmenter l’effort.
Des livrables concrets
Savoir ce qui fonctionne. Décider quoi corriger.
L’évaluation est structurée autour des décisions que le responsable produit doit prendre et de ce que l’équipe d’ingénierie doit exécuter ensuite.
- 01
Ce qui fonctionne et ce qui empêche le projet de démarrer
État du build, notes d’environnement et blocages clairement consignés.
- 02
Carte de l’architecture
Systèmes centraux, dépendances, limites de responsabilité et couplages critiques.
- 03
Registre des risques priorisé
Constats classés selon leur impact, leur probabilité et leur urgence pour la livraison.
- 04
Constats de performance et d’intégration
Des preuves mesurées sur la plateforme, l’appareil ou le casque concerné.
- 05
Orientation technique
Une recommandation argumentée pour terminer, refactoriser ou reconstruire, sans réécriture réflexe.
- 06
Un plan de réparation en étapes claires
Jalons, critères d’acceptation, dépendances et prochaines décisions utiles.
L’analyse se concentre sur les questions principales convenues. Une analyse de 20 à 40 heures ne peut pas trouver tous les bugs d’un grand projet existant. Le rapport précise donc aussi ce qui a été vérifié et les incertitudes restantes.
Déroulement de l’évaluation
Comprendre le travail avant d’investir dans les réparations.
- 01
Brief et accès
Précisez le produit, la plateforme cible, le blocage actuel et les critères de réussite. Prévoyez un accord de confidentialité avant l’accès au dépôt si nécessaire.
- 02
Vérifier si le projet fonctionne
Exécuter le projet, reproduire le problème et documenter le chemin réel de compilation avant de faire des promesses de livraison.
- 03
Examiner et mesurer
Retracer l’architecture, les dépendances, les flux de données, les intégrations et les performances sur la cible pertinente.
- 04
Décider et ordonner
Recommander les premières corrections, expliquer les possibilités et proposer un premier travail raisonnable à partir des constats.
La décision centrale
Terminer, refactoriser ou reconstruire ?
La réponse doit suivre les contraintes produit et les preuves, pas les goûts, la panique ou les coûts déjà engagés.
Terminer01
Préserver le cœur fonctionnel.
Lorsque l’architecture reste exploitable, concentrer l’effort sur les blocages, la validation et les lacunes critiques pour la publication.
Refactoriser02
Améliorer les parties qui posent problème.
Lorsque des modules précis créent un risque, les isoler et les réparer sans déstabiliser tout le produit.
Reconstruire03
À utiliser uniquement lorsque les preuves le justifient.
Une réécriture ne devient défendable que si la structure actuelle ne peut pas atteindre le résultat requis pour le produit.
Preuves pertinentes
L’expérience de livraison derrière l’évaluation.
Les décisions d’architecture s’appuient sur une expérience concrète de livraison de titres PCVR publiés, de logiciels mobiles en production et de jeux riches en systèmes.
PCVR publié sur Steam
Reach The Beat
Seul ingénieur Unity et responsable technique de l’architecture, du gameplay et des systèmes XR, des outils, des builds, de la validation matérielle et de la publication.
Voir la preuve sur SteamAndroid / iOS en production
Produit mobile confidentiel
Seul ingénieur du client Unity et architecte mobile pour l’interface complexe, les parcours dépendant du backend, la validation sur appareils et les intégrations natives.
Identité du produit non divulguée · Respect de la confidentialité
Jeux riches en systèmes
Systèmes produit interconnectés
Architecture et implémentation couvrant progression, sauvegardes, localisation, analyse et systèmes de contenu pilotés par les données.
Plus de 5 ans d’expérience commerciale Unity · Note publique Upwork : 5,0
Questions avant l’accès
Des premières étapes claires.
01Pouvez-vous reprendre un projet Unity existant ou abandonné ?
Oui. Je vérifie d’abord si le projet fonctionne, examine son code et identifie ce qui peut être réparé ou réutilisé. Je recommande une première étape avant d’estimer un travail de développement plus important.
02De quels accès avez-vous besoin ?
Pour l’évaluation elle-même : généralement le dépôt, la version Unity, un build représentatif, la documentation disponible et l’accès à la plateforme cible ou au contexte matériel. Commencez par un aperçu général. Un accord de confidentialité peut précéder les détails sensibles ou l’accès au dépôt.
03L’évaluation nous dira-t-elle s’il faut terminer, refactoriser ou reconstruire ?
C’est l’un de ses objectifs principaux. La recommandation est liée aux preuves, aux contraintes produit, aux risques de livraison et à la définition de la réussite, sans préférence systématique pour les réécritures.
04Pouvez-vous mettre en œuvre la feuille de route après l’audit ?
Oui. Votre équipe peut utiliser le rapport, ou nous pouvons convenir séparément de corrections, d’améliorations ciblées du code, de performances, de connexions aux services ou de préparation de la sortie. L’analyse ne vous engage pas à poursuivre les travaux.
05Quelle est l’ampleur de la première mission ?
Nous commençons par une analyse payante. Pour un projet repris ou des problèmes mal définis, 20 à 40 heures peuvent convenir. Nous définissons les heures, le prix, les questions principales et le rapport avant de commencer. Vous recevez un état de ce qui fonctionne ou empêche le projet de démarrer, les risques principaux et une première étape de réparation proposée. Le développement est estimé séparément.
Commencer par le blocage
Dites-moi ce qui cesse régulièrement de fonctionner.
Un budget limité ? Indiquez votre priorité et la fourchette qui vous convient. Je vous dirai clairement quelle première étape est réaliste.
La confidentialité dès le premier échange
Je comptabilise les actions de contact de façon agrégée, sans identifiants de visiteurs ni contenu des messages.
Besoin d’un autre type d’aide ?
Tous les servicesCréer un jeu
Développement de jeux
Créer une application hors jeu
Développement d’applications
Faire avancer un produit
Responsable technique Unity à temps partiel
Réactiver et retester un produit
Mises à jour & maintenance d’anciens projets Unity
Relier l’IA à un véritable processus
Connexions à l’IA & essais d’IA privée
Réunir les bonnes compétences
Développement avec des spécialistes créatifs et du test
Vérifier la qualité avant la prochaine étape