Bilan de projet : votre projet logiciel est-il en difficulté ?

Répondez à 30 questions courtes sur les délais, le budget, l’équipe, le code, la communication, les exigences et qui détient les accès. En cinq minutes, vous obtenez un verdict vert, orange ou rouge, un score pour chaque domaine et un plan d’action sur 14 jours.

Gratuit · 5 minutes · sans inscription · vos réponses ne sont pas conservées

Pas un audit d’un prestataire. Il s’agit d’une auto-évaluation fondée sur vos propres réponses. Ce n’est ni un audit, ni une évaluation d’un prestataire, d’une équipe ou d’une personne nommément désignés. Nous ne demandons, ne collectons ni ne conservons le nom de votre prestataire.

Bilan de projet — votre projet logiciel est-il en difficulté ?

D’abord, un peu de contexte

Seul le rôle est obligatoire. Le reste adapte les questions et les prochaines étapes ; cela ne change pas le score.

Ce que nous vérifions

Six domaines qui déterminent si un projet logiciel se termine bien. Chacun comporte quatre ou cinq questions factuelles — sur ce qui se passe, pas sur votre ressenti. Plus un contrôle à part de l’accès et de la propriété : il n’entre pas dans le score, mais il peut empêcher un projet d’être vert.

  • Délais

    Les livraisons arrivent-elles à la date convenue, et pouvez-vous voir un logiciel qui fonctionne ?

    Exemple: Quel est le retard de la prochaine livraison ou du prochain jalon par rapport au planning convenu ?

  • Budget

    L’argent dépensé correspond-il à l’avancement que vous avez réceptionné, et le coût pour terminer est-il connu ?

    Exemple: Par rapport au plan, combien avez-vous dépensé en plus pour l’avancement obtenu ?

  • Équipe

    Rotation, dépendance à des personnes clés, capacité réelle et expérience des parties difficiles.

    Exemple: Combien de personnes clés sont parties ou ont été remplacées au cours des 3 derniers mois ?

  • Code et dette technique

    Qui maîtrise le code, comment il est compilé, testé et livré, et si quelqu’un a regardé à l’intérieur.

    Exemple: Votre entreprise contrôle-t-elle le dépôt du code source ?

  • Communication

    À quelle fréquence vous voyez l’avancement, à quel moment vous apprenez les problèmes et si les comptes rendus correspondent à la réalité.

    Exemple: À quelle fréquence recevez-vous un point d’avancement ou une démo ?

  • Produit et exigences

    Exigences écrites, stabilité du périmètre, un décideur de votre côté et un objectif mesurable.

    Exemple: Les exigences et les critères de recette sont-ils écrits et à jour ?

  • Accès et propriété

    Qui possède le nom de domaine, les serveurs, les comptes de stores et de services, la propriété intellectuelle du code et les validations des jalons.

    Exemple : au nom de qui sont le nom de domaine, l’hébergement et les comptes cloud ?

Comment fonctionne le score

  1. Un score pour chaque domaine

    Chaque réponse vaut de 0 à 3 points de risque, et les questions les plus importantes pèsent davantage. Chaque domaine reçoit un score de 0 à 100 ; le total est une moyenne pondérée des six domaines. 75 et plus, c’est vert ; de 50 à 74, orange ; en dessous de 50, rouge.

  2. Une catastrophe ne se dilue pas dans la moyenne

    Une moyenne peut masquer une catastrophe isolée, c’est pourquoi des garde-fous s’appliquent en plus : pas d’accès au code, rien de fonctionnel à voir, des paiements très en avance sur le travail réceptionné ou aucune nouvelle pendant des semaines sont des signaux critiques. Un signal critique ou un domaine très faible empêche le projet d’être vert ; deux de l’un ou de l’autre le font passer au rouge. Les signaux d’alerte sur l’accès et la propriété fonctionnent de la même façon : par exemple, le nom de domaine et l’hébergement ne sont pas les vôtres, ou le prestataire conserve la propriété intellectuelle du code.

  3. « Je ne sais pas » est une réponse

    Ne pas savoir compte comme un risque moyen, pas comme « tout va bien ». Si vous ne savez pas répondre à la moitié d’un domaine, il est marqué « données insuffisantes » et le projet ne peut pas être vert. Avec moins de quatre domaines renseignés, nous ne donnons aucun verdict.

Que faire si le résultat est rouge

  • Sécurisez l’accès au code et à l’hébergement. Des droits administrateur, par écrit, cette semaine — quoi qu’il arrive ensuite.
  • Demandez une démo du build fonctionnel. En partage d’écran, sous cinq jours ouvrés.
  • Suspendez les paiements anticipés. Ne payez que les jalons réceptionnés selon des critères écrits.
  • Obtenez une revue indépendante. Elle prend quelques jours et fonde sur des faits le choix entre redresser, restructurer ou transférer.

Nous pouvons nous en occuper pour vous : revue de code et modernisation, des ingénieurs senior pour renforcer votre équipe ou une équipe dédiée pour reprendre le projet.

Pour aller plus loin : comment planifier un projet logiciel, pourquoi les estimations se trompent et les signaux d’alerte d’un contrat de développement.

FAQ

Que mesure le Bilan de projet ?

Six domaines qui déterminent si un projet logiciel se termine bien : délais, budget, équipe, code et dette technique, communication, produit et exigences, plus un contrôle à part de l’accès et de la propriété. Vous répondez à 30 questions factuelles et obtenez un score par domaine, un verdict global vert, orange ou rouge, un scénario recommandé et un plan d’action sur 14 jours.

S’agit-il d’un audit ou d’un jugement sur mon prestataire ?

Non. Il s’agit d’une auto-évaluation fondée sur vos propres réponses. Ce n’est ni un audit, ni une évaluation d’un prestataire, d’une équipe ou d’une personne nommément désignés. Nous ne demandons, ne collectons ni ne conservons le nom de votre prestataire.

Mes réponses sont-elles conservées ou partagées ?

Non. Le score est calculé dans votre navigateur, et les réponses ne vivent que dans cet onglet jusqu’à sa fermeture. Si vous demandez le plan complet, la demande ne contient que les codes de vos réponses et le résultat, ainsi que les coordonnées que vous saisissez.

Comment le score est-il calculé et qui a fixé les pondérations ?

Chaque réponse ajoute de 0 à 3 points de risque, pondérés selon l’importance de la question ; chaque domaine reçoit un score de 0 à 100 et le total est une moyenne pondérée. Des garde-fous empêchent qu’un seul problème critique se dilue dans la moyenne. Les pondérations et les seuils sont une proposition de travail fondée sur notre expérience de livraison et sont en cours de calibrage sur des projets réels.

Mon résultat est rouge — que faire en premier ?

Sécurisez un accès administrateur au code et à l’hébergement, demandez une démo en direct du build fonctionnel sous cinq jours et suspendez les paiements anticipés jusqu’à la recette du prochain jalon. Obtenez ensuite une revue indépendante et décidez : continuer avec un plan de redressement, restructurer, ou transférer à une autre équipe.

Puis-je l’utiliser pour une équipe interne ?

Oui. Choisissez « Notre propre équipe » à l’étape du contexte : les questions qui n’ont de sens qu’avec un prestataire externe — paiements en avance sur le travail réceptionné, demandes de modification, accès au code, comptes rendus face à la réalité — sont masquées et ne sont pas comptées.

Qui doit le remplir — le dirigeant ou le chef de projet ?

Idéalement les deux, séparément. Là où le dirigeant et le chef de projet répondent différemment, cet écart est en soi un constat.

YuSMP peut-il reprendre ou redresser un projet ?

Oui. Cela commence par une revue indépendante du code, du planning et du périmètre restant ; nous signons votre NDA au préalable si nécessaire. Ensuite, vous décidez de redresser le projet avec l’équipe actuelle, de le restructurer ou de le transférer.

Pourquoi l’accès et la propriété sont-ils contrôlés séparément ?

Parce que cela détermine si vous pouvez même changer de cap. Si le nom de domaine, l’hébergement, les comptes de stores ou la propriété intellectuelle du code restent chez le prestataire, changer d’équipe devient lent et risqué, quelle que soit la qualité du reste. L’accès n’entre pas dans le score, mais un signal d’alerte (par exemple, aucun accès à l’hébergement ou aucune cession de propriété intellectuelle dans le contrat) empêche le projet d’être vert, et deux le font passer au rouge.

Que contient le plan d’action sur 14 jours ?

Ce qu’il faut faire demain (généralement les accès, l’argent et un build fonctionnel), ce qu’il faut faire la première semaine (les réponses qui font baisser le score et, si besoin, une revue de code) et ce qu’il faut faire la deuxième semaine (redresser le domaine le plus faible), avec un point de décision au jour 14. Vous voyez le plan à l’écran et le recevez en PDF par e-mail.

Cinq minutes maintenant peuvent faire gagner des mois plus tard

30 questions, sans inscription, vos réponses restent dans votre navigateur.

Évaluer mon projet

Outils et guides associés

Auto-évaluation, pas un audit. Ne constitue pas un conseil juridique ou financier. Tarifs · Modernisation logicielle · Renfort d’équipe · Équipes dédiées