Notre méthode

Piloter un projet deeptech par les preuves

Réduire le risque étape par étape : traiter d'abord ce qui peut faire échouer le projet, et décider sur des faits plutôt que sur des livrables.

Parler à un expert Comprendre l'échelle TRL

En bref

La méthode Innowide consiste à piloter un projet deeptech par les preuves plutôt que par les livrables. Nous identifions d'abord les hypothèses critiques qui peuvent faire échouer le projet, puis nous les testons par boucles courtes, avec des prototypes conçus comme des instruments de décision. Chaque cycle produit des données qui permettent de poursuivre, de réorienter ou d'arrêter. Nous appliquons cette approche, issue de l'agilité et adaptée au hardware, entre les TRL 2 et 6.

Principe n°1

Piloter une courbe d'incertitude, pas un planning

Au démarrage, un projet deeptech n'a pas d'abord besoin d'un macro-planning détaillé, mais d'une lecture explicite de ses incertitudes critiques. Nous en distinguons cinq familles.

Valeur

Le problème adressé est-il assez important ? La solution apporte-t-elle un gain significatif ?

Technique

La solution peut-elle atteindre la performance attendue ? Quelles limites physiques peuvent la bloquer ?

Intégration

S'insère-t-elle dans le système ? Interfaces, environnement et sécurité sont-ils maîtrisables ?

Industriel

Peut-on la fabriquer, la qualifier, l'approvisionner, la maintenir et la faire passer à l'échelle ?

Organisationnel

A-t-on les compétences, le sponsor, le rythme de décision et la gouvernance pour avancer ?

Principe n°2

Un livrable rassure. Une preuve permet de décider.

Les livrables sont utiles, mais ils deviennent trompeurs lorsqu'ils ne sont reliés à aucune preuve. Un prototype peut être livré sans avoir répondu à la bonne question.

Un livrable montre que quelque chose a été produit

  • Une maquette ou un prototype
  • Un rapport d'étude
  • Une architecture cible
  • Une feuille de route

Une preuve montre que quelque chose a été appris

  • Une mesure confirmant un niveau de performance
  • Un test révélant une limite physique
  • Une comparaison entre deux architectures
  • Un essai révélant une contrainte d'intégration

Principe n°3

Relier chaque action à une décision

Une chaîne simple, mais exigeante : elle évite à la fois le projet trop abstrait et le projet trop activiste.

  1. Vision

    Quelle ambition sert-on, pour quel impact concret ?

  2. Verrous

    Quels verrous peuvent invalider cette ambition ?

  3. Artéfacts

    Quel artéfact minimal (prototype, banc, simulation) permet de les lever vite ?

  4. Décision

    Quelle conséquence tirera-t-on du résultat ?

Le dossier de décision

À la fin de chaque itération, le même document, court : ce que nous avons testé, ce que nous avons mesuré, le niveau de maturité atteint, ce qui tient, ce qui ne tient pas, la décision que nous recommandons et ce qu'elle engage. Il se termine par la proposition de l'itération suivante, avec sa preuve attendue et son prix. Quand la mesure dit d'arrêter, nous l'écrivons.

Notre démarche

Quatre étapes, répétées par boucles courtes

Nous traitons d'abord ce qui peut faire échouer le projet. Chaque cycle développe, teste et valide les points critiques avant de mobiliser davantage de ressources.

  1. Cadrer le verrou

    Identifier ce qui peut faire échouer le projet et formuler les hypothèses critiques à tester.

  2. Idéer et concevoir

    Explorer les pistes techniques et concevoir les solutions candidates.

  3. Prototyper

    Construire vite des prototypes pensés comme des instruments de décision, pas comme des produits finis.

  4. Expérimenter et décider

    Tester, mesurer, puis remettre un dossier de décision : poursuivre, réorienter ou arrêter.

Un prototype n'est pas une maquette : c'est un instrument de décision.

Agile for Hardware

Garder l'esprit agile, adapter les tactiques au réel

Copier les pratiques du logiciel mène souvent à l'impasse en deeptech. Les principes agiles restent puissants ; ce sont les tactiques qu'il faut adapter aux contraintes du hardware.

Ce que nous conservons

  • L'obsession de la valeur : prioriser ce qui réduit un risque structurant
  • Des boucles de feedback qui transforment les hypothèses en faits
  • L'adaptation au changement, car l'incertitude fait partie du terrain
  • L'autonomie des équipes, dans un cadre et des critères de décision clairs

Ce que nous adaptons

  • Un cadrage initial avant d'itérer : intention, verrous, critères de décision
  • Deux rythmes : des sprints disciplinaires courts et des itérations système
  • Des prototypes conçus pour répondre à une question, pas pour impressionner
  • Des jalons organisés autour des décisions plutôt que des livraisons

Les quatre dimensions d'un cycle utile

Un objectif d'intégration

Pas « qu'allons-nous faire ? » mais « qu'allons-nous rendre testable ensemble ? »

Une stratégie de prototype

Ne pas confondre vitesse de fabrication et vitesse d'apprentissage.

Un alignement assumé

Synchroniser les disciplines aux moments où c'est indispensable, pas en permanence.

Une confrontation au terrain

Intégrer tôt ce que le réel accepte, refuse ou transforme.

Échelle TRL

Comprendre la maturité technologique

L'échelle TRL (Technology Readiness Level) décrit la maturité d'une technologie en neuf niveaux, de l'observation d'un principe (TRL 1) à l'exploitation en conditions réelles (TRL 9). Innowide intervient entre les TRL 2 et 6, là où les points critiques restent à prouver.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
Zone d'intervention Innowide · TRL 2 → 6

TRL 1 à 3

Du principe à la preuve de concept

Ce que cela prouve
Un principe peut être mobilisé et une première démonstration obtenue en conditions contrôlées.
Ce que cela ne prouve pas
Que la solution est robuste, intégrable ou fabricable.

TRL 4 à 5

Validation en laboratoire ou environnement représentatif

Ce que cela prouve
La technologie fonctionne au-delà d'une démonstration isolée, de façon reproductible.
Ce que cela ne prouve pas
Que l'environnement simulé reflète les conditions réelles.

TRL 6 à 7

Démonstration en environnement pertinent ou opérationnel

Ce que cela prouve
Un démonstrateur fonctionne en environnement pertinent ; l'architecture devient crédible.
Ce que cela ne prouve pas
Que la technologie est industrialisable ou que l'intégration système est sans risque.

TRL 8 à 9

Qualification et conditions réelles

Ce que cela prouve
La technologie est qualifiée et éprouvée en conditions réelles.

Ce que le TRL ne mesure pas

Maturité industrielle

Fabriquer à coût, cadence et qualité acceptables : c'est le rôle du MRL.

Maturité d'intégration

Une brique mature comme composant peut rester immature comme système.

Maturité de qualification

Les exigences réglementaires ou de certification du secteur.

Maturité d'usage

Ce que les utilisateurs et l'environnement opérationnel acceptent réellement.

Et votre organisation ? Mesurez en 5 minutes votre maturité sur l'agilité hardware, l'incertitude technologique ou le prototypage.

Faire l'auto-diagnostic

FAQ

Questions fréquentes sur la méthode

Qu'est-ce que le pilotage par les preuves ?

C'est organiser un projet autour de ce qui a été appris plutôt que de ce qui a été produit. Un livrable montre que quelque chose existe ; une preuve réduit une incertitude et permet de décider : une mesure, un test, une comparaison ou un essai d'intégration.

Qu'est-ce que l'Agile for Hardware ?

C'est une manière d'appliquer les principes agiles (valeur, feedback, adaptation) aux projets hardware et deeptech, en adaptant les tactiques : cadrage initial avant d'itérer, prototypes conçus comme instruments de décision, et deux rythmes combinant sprints disciplinaires courts et itérations système.

Pourquoi les sprints ne suffisent-ils pas en hardware ?

Parce qu'un sprint construit autour d'une somme de tâches n'accélère pas l'apprentissage. En hardware, un cycle utile se construit autour d'un objectif d'intégration, d'une stratégie de prototype, d'un alignement assumé entre disciplines et d'une confrontation au terrain.

Qu'est-ce que l'échelle TRL ?

L'échelle TRL (Technology Readiness Level) mesure la maturité d'une technologie en neuf niveaux, de l'observation d'un principe (TRL 1) à l'exploitation en conditions réelles (TRL 9). Innowide intervient entre les TRL 2 et 6.

Le TRL suffit-il à évaluer la maturité d'un projet ?

Non. Le TRL mesure la maturité technologique, pas la maturité industrielle (MRL), d'intégration, de qualification ou d'usage. Un projet peut être avancé en TRL et encore très immature sur l'industrialisation.

Qu'est-ce qu'un prototype « instrument de décision » ?

C'est un prototype conçu pour réduire une incertitude prioritaire, pas pour montrer qu'on avance. Il répond à une question précise : valider un principe, comparer deux options, mesurer une performance ou révéler une contrainte d'intégration.

Pour aller plus loin

Mettre la méthode en pratique

Technologie à valider

Recherches & Technologies

Transformer les hypothèses en preuves concrètes avant arbitrage.

Découvrir l'expertise

Projet flou ou bloqué

Innover en incertitude

Identifier les priorités critiques et remettre le projet en mouvement.

Découvrir l'expertise

Aller plus vite

Tech Studio

Accélérer grâce à des briques techniques explorées et maturées en amont.

Découvrir l'expertise

Appliquons la méthode à votre projet.

30 minutes pour identifier vos hypothèses critiques et la première preuve à produire.

Parler à un expert