Aller au contenu
Recherche CODT Technologies

Le temps qu'un logiciel réel met à sortir.

La plupart des délais de livraison qu'on trouve en ligne sont des fourchettes marketing — inventées pour le clic, rattachées à aucun projet réel. Ce rapport prend l'autre route : des benchmarks anonymisés compilés à partir des propres relevés de livraison de CODT Technologies pour des produits clients réellement mis en production — combien de semaines entre le lancement et le v1, quelle équipe l'a construit, et où est passé le temps.

La réponse courte
Données à venir

Une phrase, écrite à partir du jeu de données : le délai médian entre le lancement et le v1 sur les produits livrés par CODT Technologies, avec la dispersion autour. Publiée seulement une fois les relevés sous-jacents compilés et vérifiés.

Médiane lancement → v1
Données à venir

Nombre médian de semaines entre un lancement signé et un v1 entre les mains de vrais utilisateurs, sur tout le jeu de données.

Produits dans le jeu de données
Données à venir

Nombre de produits livrés dont les relevés satisfont aux règles d'inclusion ci-dessous.

Période couverte
Données à venir

Première et dernière dates de lancement du jeu de données, indiquées à l'année.

Brouillon — jeu de données en préparation

Ce rapport publie d'abord sa méthodologie. Chaque emplacement chiffré de cette page porte la mention « Données à venir » tant que les relevés de livraison sous-jacents ne sont pas compilés et vérifiés — rien ici n'est une estimation, et aucun emplacement ne sera jamais rempli avec une estimation. Les chiffres seront publiés une fois, correctement, ou pas du tout.

Méthodologie

D'où viendront les chiffres.

Un benchmark ne vaut d'être cité que si l'on peut voir comment il a été fabriqué. Voici les règles sous lesquelles ce rapport est construit — fixées avant la publication du moindre chiffre, pour que les données ne puissent pas être discrètement tordues en faveur du résultat.

  1. Source de référence

    Chaque chiffre est tiré des artefacts de livraison internes de CODT Technologies — plans de projet, validations de jalons, historique des versions et relevés de facturation — pour des produits réellement mis en production. Rien n'est reconstitué de mémoire, collecté par sondage ou emprunté à des études tierces. Un chiffre qui ne peut être rattaché à un artefact de livraison n'entre pas dans le jeu de données.

  2. Ce qui compte comme lancement

    Le chronomètre démarre au premier sprint de travail de la mission signée — pas au premier contact, pas à la proposition. Les échanges d'avant-vente et le cadrage non facturé sont exclus : le délai mesure la livraison, pas le cycle de vente.

  3. Ce qui compte comme v1

    Le chronomètre s'arrête à la première mise en production entre les mains de vrais utilisateurs — une version sur laquelle l'activité du client fonctionne réellement. Les bêtas internes, les démonstrations et les jalons de préproduction ne comptent pas. La ligne est volontairement stricte : c'est celle qui intéresse les acheteurs.

  4. Anonymisation

    Les noms de clients ne sont jamais publiés dans le jeu de données. Les produits apparaissent sous des libellés anonymisés accompagnés d'un type de plateforme, les dates ne sont indiquées qu'à l'année, et tout chiffre qui identifierait un client à lui seul est publié sous forme d'agrégat. Les missions sous NDA sont entièrement exclues des données ligne à ligne.

  5. Inclusions et exclusions

    Le jeu de données couvre les produits clients livrés qui satisfont aux définitions ci-dessus. Les projets mis en pause, annulés ou absorbés dans d'autres développements sont exclus — et le rapport publié dira combien ont été exclus et pourquoi, car un benchmark qui cache ses exclusions est une publicité.

  6. Précision honnête

    Le jeu de données d'une seule entreprise supporte des médianes et des fourchettes — pas une précision à la décimale ni des courbes de percentiles. Les chiffres sont publiés à la précision que l'échantillon supporte honnêtement, et chaque agrégat est imprimé à côté du n et de la période sur lesquels il a été calculé.

n — produits inclus
Données à venir

Décompte final après application des règles d'inclusion aux relevés de livraison.

Période
Données à venir

Années de lancement couvertes par le jeu de données, de la plus ancienne à la plus récente.

Produits exclus
Données à venir

Nombre de projets exclus, avec les raisons indiquées dans le rapport publié.

Résultats

Ce que montreront les relevés de livraison.

Quatre questions, toutes traitées à partir du même jeu de données. Tant que les relevés ne sont pas compilés et vérifiés, chaque emplacement ci-dessous indique exactement ce qu'il contiendra — et ne contient rien d'autre.

Du lancement au v1 : le délai global

La question

Combien de semaines s'écoulent entre un lancement signé et un v1 entre les mains de vrais utilisateurs ?

C'est le chiffre que tout fondateur réclame et que presque aucune agence ne publie à partir de relevés réels. Les chiffres publiés ici seront les délais lancement–v1 médian, le plus rapide et le plus lent du jeu de données — sous la définition stricte du v1 ci-dessus, pour qu'une démonstration ne se fasse jamais passer pour un lancement.

Semaines médianes jusqu'au v1
Données à venir

Médiane lancement → v1 sur tous les produits du jeu de données.

v1 le plus rapide
Données à venir

Délai lancement → v1 le plus court du jeu de données, en semaines.

v1 le plus long
Données à venir

Délai lancement → v1 le plus long du jeu de données, en semaines.

Lancement → v1, produit par produit
ProduitType de plateformeSemaines jusqu'au v1Taille de l'équipe cœur
Données à venir

Une ligne anonymisée par produit livré : libellé (P01, par exemple), type de plateforme, lancement → v1 en semaines, et taille de l'équipe cœur à la livraison.

Analyse en attente des données

La lecture écrite des données de délai : où se situe la médiane, ce qui séparait les projets les plus rapides des plus lents, et ce que cela implique pour cadrer un v1.

Le délai par type de produit

La question

Une application mobile sort-elle vraiment plus vite qu'une plateforme SaaS ou qu'un agent vocal ?

« Combien de temps prend une application » n'appelle pas la même réponse honnête que « combien de temps prend une plateforme multi-tenant » — et c'est en mélangeant les deux qu'on fabrique des moyennes trompeuses. Ce résultat séparera les délais par type de plateforme, avec le n de chaque groupe imprimé à côté, pour qu'un groupe trop mince ne soit jamais pris pour une tendance.

Catégorie la plus rapide (médiane)
Données à venir

Type de plateforme au délai lancement → v1 médian le plus court, et cette médiane en semaines.

Catégorie la plus lente (médiane)
Données à venir

Type de plateforme au délai lancement → v1 médian le plus long, et cette médiane en semaines.

Écart le plus large
Données à venir

Type de plateforme dont l'amplitude du plus rapide au plus lent est la plus large du jeu de données.

Délai médian par type de plateforme
Type de plateformeProduits (n)Semaines médianes jusqu'au v1Amplitude (semaines)
Données à venir

Une ligne par type de plateforme — mobile, SaaS / plateforme web, IA et agents vocaux, IoT — avec la taille du groupe, le délai médian et l'amplitude. Les groupes trop petits pour être agrégés honnêtement seront fusionnés et signalés comme tels.

Analyse en attente des données

La comparaison écrite entre types de produits : quelles catégories prennent réellement plus de temps, de combien, et où l'écart à l'intérieur d'une catégorie pèse plus lourd que la différence entre catégories.

Taille et composition de l'équipe

La question

Combien de personnes faut-il réellement pour livrer un v1 ?

La taille d'équipe est le terrain où les mythes de livraison courent le plus vite — du génie solitaire au programme de quarante personnes. Le jeu de données enregistrera l'équipe cœur qui a réellement construit chaque produit livré, et la répartition de cet effectif entre les rôles d'ingénierie, de design et de produit.

Équipe cœur médiane
Données à venir

Taille médiane de l'équipe cœur sur tous les produits du jeu de données.

Plus petite équipe ayant livré
Données à venir

Plus petite équipe cœur ayant mené un produit du jeu de données jusqu'au v1.

Plus grande équipe cœur
Données à venir

Plus grande équipe cœur enregistrée pour un seul produit du jeu de données.

Composition de l'équipe cœur sur l'ensemble du jeu de données
RôleEffectif typePart des produits dotés du rôle
Données à venir

Une ligne par rôle — ingénierie, design, produit/delivery, QA — avec l'effectif type sur un v1 livré et le nombre de produits ayant effectivement pourvu le rôle.

Analyse en attente des données

La lecture écrite des données d'effectif : l'équipe cœur type derrière un v1 livré, la façon dont la composition a varié avec le type de produit, et ce que cela implique pour budgéter une équipe.

Où passent les semaines : la répartition par phase

La question

Quelle part d'une livraison relève de la discovery, du design, de la construction et du durcissement ?

Les acheteurs se représentent un calendrier comme une longue « construction » — puis découvrent les parties que personne n'annonçait : le cadrage, le design, le durcissement des intégrations, le lancement. Le jeu de données découpera le calendrier de chaque produit en phases, pour que la forme publiée d'une livraison corresponde à la vraie, y compris l'ingrate étape entre le moment où les fonctionnalités sont complètes et la mise en production.

Part discovery + design
Données à venir

Part médiane du calendrier passée en cadrage et en design, sur l'ensemble du jeu de données.

Part construction
Données à venir

Part médiane du calendrier passée en implémentation.

Part durcissement + lancement
Données à venir

Part médiane du calendrier passée en QA, durcissement des intégrations et lancement.

Part médiane de chaque phase dans le calendrier de livraison
PhasePart médiane du calendrierCe que la phase couvre
Données à venir

Une ligne par phase — discovery et cadrage, design, construction, durcissement et QA, lancement — avec sa part médiane du délai lancement → v1 et une définition d'une ligne, l'ensemble formant le tout.

Analyse en attente des données

La lecture écrite des données de phase : quelle phase domine le calendrier, laquelle est la plus sous-estimée, et comment la forme change sur les projets chargés d'intégrations.

Limites

Ce que ce rapport peut et ne peut pas affirmer.

Tout jeu de données a ses bords. Les nommer est ce qui sépare la recherche du marketing — voici ceux que ce rapport porte par construction.

  • Les données d'un seul studio

    Ce sont les relevés de livraison de CODT Technologies, pas un échantillon sectoriel. Un modèle de mission à périmètre ferme, mené par des seniors, façonne chacun de ces chiffres : ils décrivent notre façon de livrer et se généralisent aux équipes qui travaillent de la même manière, pas à tout le logiciel partout.

  • Uniquement des produits livrés

    Le jeu de données mesure des produits arrivés jusqu'au v1. Les projets mis en pause ou annulés sont exclus des délais — le rapport publié dira combien et pourquoi, mais le biais du survivant fausse tout de même ce qu'un jeu de données de finisseurs peut dire de ceux qui démarrent.

  • Les définitions déplacent les chiffres

    Le délai lancement–v1 dépend entièrement de l'endroit où l'on trace ces deux lignes, et les nôtres sont strictes. Comparer ces chiffres à d'autres délais publiés hérite de chaque écart de définition — une comparaison n'est honnête qu'entre études qui tracent les mêmes lignes.

  • Un petit jeu de données, délibérément

    Le portefeuille livré d'une seule entreprise supporte des médianes et des fourchettes, pas des courbes de distribution. Lorsqu'un groupe est trop petit pour être agrégé honnêtement, le rapport le fusionnera ou l'omettra et le dira — des données minces présentées avec aplomb sont précisément le travers que cette page existe pour éviter.

  • Les longues missions pèsent sur les données

    Certains produits des relevés appartiennent à de longues missions de plateforme multi-produits, où les produits suivants sortent sur une infrastructure que les précédents ont payée. Là où cela façonne un chiffre de façon significative, le rapport le signalera plutôt que de laisser un avantage cumulé passer pour de la vitesse brute.

Citation

Comment citer ce rapport.

Ce rapport existe pour être cité — avec attribution et un lien. Les chiffres pourront être révisés lorsque le jeu de données sera étendu ; une citation devrait donc nommer l'édition, et chaque révision sera signalée sur cette page.

CODT Technologies — Benchmarks de livraison logicielle. [données à venir: edition]. https://codttech.com/research/software-delivery-benchmarks

L'édition et la date de publication sont fixées au moment où le jeu de données vérifié est publié.

Les chiffres et tableaux de ce rapport peuvent être reproduits avec attribution à CODT Technologies et un lien vers cette page.

FAQ

Les questions posées sur cette recherche

Un point non couvert ?

Décrivez-le dans un brief. Un ingénieur senior — pas un commercial — répond sous un jour ouvré.

D'où viennent les données de ce rapport ?

Des relevés de livraison internes de CODT Technologies pour des produits clients livrés — plans de projet, validations de jalons, historique des versions et relevés de facturation. Pas de sondage, pas d'étude tierce, pas d'estimation : un chiffre qui ne peut être rattaché à un artefact de livraison n'entre pas dans le jeu de données.

Pourquoi chaque chiffre porte-t-il la mention « données à venir » ?

Parce que l'ordre honnête est : méthodologie d'abord, chiffres ensuite. Cette page fixe les définitions, les règles d'inclusion et les standards d'anonymisation avant la publication du moindre chiffre, et les emplacements de données restent visiblement vides tant que les relevés sous-jacents ne sont pas compilés et vérifiés. Rien sur cette page n'est une estimation — un emplacement vide est plus honnête qu'un emplacement plausible.

Comment définissez-vous un v1 ?

La première mise en production entre les mains de vrais utilisateurs — une version sur laquelle l'activité du client fonctionne réellement. Les bêtas internes, les démonstrations et les jalons de préproduction ne comptent pas, et le chronomètre démarre au premier sprint de travail de la mission signée, pas au premier contact. Des lignes strictes gardent le benchmark comparable et difficile à truquer.

Les noms de clients sont-ils publiés ?

Non. Les produits apparaissent sous des libellés anonymisés accompagnés d'un type de plateforme, les dates ne sont indiquées qu'à l'année, et tout chiffre qui identifierait un client à lui seul est publié sous forme d'agrégat. Les missions sous NDA sont entièrement exclues des données ligne à ligne.

Puis-je citer ou reproduire les résultats ?

Oui — c'est tout l'intérêt de les publier. Les chiffres et tableaux peuvent être reproduits avec attribution à CODT Technologies et un lien vers cette page. Citez l'édition, puisque les chiffres pourront être révisés quand le jeu de données sera étendu ; chaque révision sera signalée ici.

Le jeu de données sera-t-il mis à jour ?

Oui, par édition : chaque édition publiée indique son n et sa période, et les produits nouvellement livrés entrent dans le jeu de données sous les mêmes règles d'inclusion. Une révision change l'édition, elle ne l'écrase jamais en silence — une citation à une édition passée reste vérifiable.

Pourquoi une agence publierait-elle ses propres délais de livraison ?

Parce que l'alternative, c'est le statu quo : des fourchettes inventées que personne n'assume. Des relevés réels, publiés avec leurs définitions et leurs limites, sont vérifiables — et un benchmark sur lequel nous acceptons d'être jugés en dit plus sur notre façon de travailler que n'importe quelle fourchette marketing. Ce sont ces mêmes relevés qui nourrissent la manière dont nous chiffrons nos devis fermes pendant les sprints de discovery.

Prêt à construire

Un problème qui mérite
d'être bien résolu ?

Parlez-nous de votre produit, votre échéance et vos contraintes. Nous vous répondrons sous un jour ouvré avec une lecture honnête de la faisabilité, du périmètre et de la bonne équipe à mobiliser.