Ingénieur hardware encore sur Excel, Google Drive et Notion ? Voici pourquoi ça ne passe pas à l'échelle

Ces outils sont excellents. Le problème n'est pas ce qu'ils font. Le problème, c'est ce qui se passe entre eux.

Regardez le stack logiciel d'une équipe hardware de 50 à 300 ingénieurs. C'est presque toujours le même. Un outil de CAO pour la géométrie. Excel pour le BOM, les budgets de masse, les matrices d'exigences. Google Drive pour les rapports d'essais, les comptes rendus de revues de conception, les fichiers de design. Notion ou Confluence pour la coordination. L'email pour les décisions. Parfois un outil d'exigences, parfois le début d'un PLM.

Chacun de ces outils est puissant dans sa propre tâche. La CAO modélise la géométrie mieux que quoi que ce soit d'autre. Excel calcule vite. Drive stocke tout. Notion documente proprement. Pris isolément, aucun n'est un mauvais choix.

Le problème est structurel : la vérité d'un système physique complexe ne vit dans aucun de ces outils. Elle vit dans les relations entre les données qu'ils contiennent. Quelle exigence a motivé quel choix d'architecture. Quel composant porte quelle fonction. Quelle révision a été testée, par qui, avec quel résultat, et sur exactement quelle configuration. Et c'est précisément aux frontières entre les outils que cette information se perd.

Des outils verticaux, des données orphelines

Un outil vertical est construit autour d'une tâche : dessiner, calculer, écrire, planifier. Il optimise cette tâche et s'arrête là. Le fichier de CAO ne sait rien de l'exigence. Le tableur du BOM ne sait rien du rapport d'essai. La page Notion ne connaît ni l'un ni l'autre. Chaque outil détient une copie partielle du système, exprimée dans son propre format, figée à sa propre date.

À chaque frontière, un humain recopie les données. Il exporte une masse depuis la CAO, la colle dans le tableur d'agrégation, reporte le total sur la page projet, l'écrit dans le fichier de revue. Quatre copies de la même quantité. Aucun lien entre elles. Le jour où la CAO change, trois copies deviennent fausses et rien ne le signale.

C'est ça, la fuite de données entre outils verticaux. Pas des fichiers perdus. De la cohérence perdue. Les fichiers sont tous là, soigneusement rangés dans Drive. Ce qui a disparu, c'est la garantie qu'ils disent la même chose au même moment.

Première faille : rien ne centralise

Un dossier Drive bien organisé donne une impression de centralisation. C'est une illusion. Drive centralise le stockage, pas la donnée. Un PDF de rapport d'essai est un objet opaque : la valeur mesurée qu'il contient n'existe pour aucun système, elle n'existe que pour l'œil humain qui ouvrira le document. Elle ne peut être ni interrogée, ni comparée, ni injectée dans un calcul, ni confrontée à la bonne révision du composant.

Une source unique de vérité n'est pas un endroit où tout est classé. C'est un endroit où chaque quantité du système existe exactement une fois, sous forme structurée, et où tout le reste la référence au lieu de la copier. Excel, Drive et Notion ne peuvent pas offrir cela : leur unité de base est le fichier ou la page, jamais l'objet d'ingénierie.

Deuxième faille : des modèles individualistes

Ouvrez trois tableurs de BOM dans la même entreprise. Vous y trouverez trois structures différentes. Des colonnes différentes, des conventions de nommage différentes, des formules d'agrégation réécrites trois fois, avec trois interprétations des cas limites. Chaque tableur est le modèle mental de son auteur, figé dans des cellules.

Ces modèles individuels ont deux conséquences. La première est l'erreur : une revue de littérature publiée en 2024 dans Frontiers of Computer Science conclut que 94 % des tableurs utilisés pour des décisions métier contiennent des erreurs, en grande partie parce que leurs auteurs construisent une logique complexe sans aucune des pratiques qualité du développement logiciel. Un BOM multi-niveaux avec des agrégations récursives de masse, de coût et de puissance, c'est exactement ce type de logique complexe.

La seconde conséquence est la dépendance aux individus. Le tableur ne survit pas à son auteur. Quand celui-ci part, l'équipe hérite d'un artefact que personne n'ose toucher. La connaissance du système est devenue tribale : elle vit dans quelques têtes, pas dans une structure partagée que chacun peut lire, vérifier et étendre.

Troisième faille : la coordination repose sur des mises à jour manuelles

Dans un stack Excel, Drive, Notion, il n'existe aucun mécanisme de propagation. Un changement de conception ne met à jour ni le BOM, ni la matrice d'exigences, ni la page projet, ni le fichier de revue. Chaque répercussion est un acte manuel, exécuté par quelqu'un qui doit d'abord savoir que le changement a eu lieu, puis se souvenir de chaque endroit où il se propage.

Les ingénieurs deviennent la couche de synchronisation du système d'information. Des analyses récentes de la gestion des données d'ingénierie estiment qu'environ 25 % du temps des équipes part dans ces tâches à valeur nulle : chercher des fichiers, réconcilier des versions contradictoires, reconstruire un contexte perdu. Une journée entière par semaine et par ingénieur, passée à maintenir à la main une cohérence que l'outillage devrait garantir.

Avec 10 ingénieurs, ça tient. Le produit est encore simple, tout le monde sait tout, les copies divergent à peine. Avec 100 ingénieurs, des variantes produit, des configurations client et des sous-traitants, le nombre de frontières croît plus vite que les effectifs. Chaque nouvelle équipe, chaque nouveau tableur, chaque nouvelle variante ajoute des copies à synchroniser. C'est la définition exacte de ce qui ne passe pas à l'échelle : le coût de coordination croît plus vite que la capacité de l'organisation à l'absorber. L'enquête Hexagon publiée en 2026 le confirme à l'échelle de l'industrie : 98 % des fabricants font état de problèmes de données qui ralentissent directement l'innovation et le time-to-market.

L'audit, quand la facture tombe

Tant que le produit avance, la fragmentation reste un coût diffus. L'audit la rend visible d'un seul coup. ISO 13485, AS9100, 21 CFR 820, dossiers de sûreté nucléaire : tous ces référentiels posent la même question sous des formes différentes. Montrez la chaîne. De l'exigence à la conception, de la conception au test, du test à la configuration livrée, avec les décisions et les responsables à chaque maillon.

Quand la donnée vit dans des fichiers, répondre à cette question est un projet en soi. Les données d'inspection de la FDA pour les exercices 2022 à 2024 placent systématiquement les CAPA et les contrôles de conception en tête des observations du formulaire 483 : gestion des exigences, vérification, validation, maîtrise documentaire. Autrement dit, ce que les inspecteurs sanctionnent le plus souvent n'est pas la qualité de l'ingénierie elle-même, mais l'incapacité à en produire une preuve structurée.

Les équipes qui préparent un audit sur un stack de fichiers le savent : la préparation prend des semaines, produit des tableurs de synthèse jetables, et dépend entièrement de la disponibilité des personnes qui détiennent l'historique. Le résultat est fragile. La question suivante de l'auditeur peut vous forcer à tout reconstruire.

Ce qu'il faut à la place

La réponse n'est pas de remplacer la CAO, ni d'interdire Excel. Les outils spécialisés restent. Ce qui manque, c'est une couche en dessous : une structure où les objets d'ingénierie du système existent exactement une fois, avec leurs relations rendues explicites.

Concrètement, cette couche fait quatre choses. Elle modélise : exigences, fonctions, composants, interfaces, tests et décisions sont des objets typés, liés entre eux, pas des lignes de tableur. Elle calcule : les agrégations de masse, de coût ou de puissance sont des attributs calculés sur le graphe produit, déterministes, recalculés à chaque changement, identiques pour tout le monde. Elle verrouille : une baseline est un état figé et versionné du système, pas un dossier daté dans Drive ; vous savez exactement ce qui a été gelé, quand, et ce qui a changé depuis. Elle trace : chaque objet porte son historique, chaque lien est navigable dans les deux sens, et la réponse à un auditeur est une requête, pas une enquête.

C'est ce que nous construisons avec Koddex : un Système d'Exploitation d'Ingénierie pour les systèmes physiques complexes. Les équipes modélisent leur produit, verrouillent leurs baselines, gèrent leurs révisions et maintiennent une traçabilité de bout en bout. Les outils verticaux continuent de faire ce qu'ils font bien. La donnée cesse de fuir entre eux.

Excel, Drive et Notion ont porté votre équipe jusqu'ici. La question n'est pas de savoir s'ils sont de bons outils. C'est de savoir si votre vérité d'ingénierie peut continuer à vivre dans des copies non synchronisées pendant que votre produit, votre équipe et vos obligations réglementaires grandissent. Les chiffres ci-dessus donnent la réponse.

Découvrez à quoi ressemble une source unique de vérité sur votre propre produit. Explorez le Système d'Exploitation d'Ingénierie ou réservez une démo.

Sources

- Poon P.-L. et al., "Spreadsheet quality assurance: a literature review", Frontiers of Computer Science, 2024. DOI 10.1007/s11704-023-2384-6.
- LatentView Analytics, "Engineering Data Management", 2026.
- Hexagon, enquête sectorielle citée dans "Trends Reshaping PLM for 2026 and Beyond", HCLTech, 2026.
- FDA, base publique d'observations d'inspection (formulaire 483), exercices 2022 à 2024, 21 CFR Part 820.