Zéro échec de projet depuis 2007 — les règles d'ingénierie qui tiennent ce bilan
J'ai fondé Software Tailor en 2006. Dix-neuf ans plus tard, l'entreprise a livré à travers quatre cycles économiques distincts, six clients du Fortune Global 500 dans la pharmacie, la finance, le gouvernement, le juridique, la défense et l'énergie, et zéro échec de projet depuis 2007. Ce dernier chiffre est celui que les investisseurs et les évaluateurs achats nous demandent le plus souvent d'expliquer, et c'est le seul qui a besoin d'une explication. Voici les quatre règles d'ingénierie qui tiennent ce bilan.
Règle 1 : un seul modèle de livraison, pas de brouillage service / produit
Chaque engagement de Software Tailor s'exécute sur le même modèle de livraison — une phase pilote au périmètre serré qui livre un logiciel fonctionnel, suivie d'une extension que le client choisit de financer (ou pas) sur la base de ce qui a été livré. Nous n'exploitons pas une pratique « services » distincte qui livrerait contre des documents d'exigences et une pratique « produit » distincte qui livrerait contre des feuilles de route. Les deux entreraient en conflit ; l'une subventionnerait toujours l'autre.
Le modèle unique signifie que chaque ingénieur sait à quoi ressemble « terminé » avant de commencer. C'est la condition préalable pour ne pas échouer.
Règle 2 : discipline sur la cohorte de clients — uniquement des clients pour lesquels nous savons livrer
Notre cohorte de clients est sélectionnée — et non opportuniste. Six clients du Fortune Global 500 en 19 ans n'est pas un pipeline de vente lent ; c'est une barre de sélection délibérée. Chaque client que nous prenons doit passer trois tests avant le lancement : son problème est un problème que nous avons déjà résolu, son sponsor interne est la personne qui utilisera le logiciel (et non une strate d'intermédiaires), et son environnement matériel/données nous permet de livrer sans détour d'approvisionnement de six mois.
Un client qui échoue à l'un de ces tests devient une recommandation vers quelqu'un d'autre, pas un projet. C'est la règle qui nous coûte le plus souvent du chiffre d'affaires. C'est aussi celle qui n'a aucune exception sur 19 ans.
Règle 3 : discipline d'ingénierie alignée sur un cadre reconnu
Bien avant que la gestion des risques liés à l'IA ait son propre cadre, les règles d'ingénierie que j'ai codifiées pour Software Tailor reproduisaient déjà la même forme : gouverner le travail, cartographier les risques, mesurer les résultats, gérer les changements. Le NIST AI RMF 1.0 [1] a formalisé ce schéma pour l'IA en 2023, et le profil Infrastructures critiques d'avril 2026 [1] l'a étendu aux secteurs réglementés. À la lecture de ces documents, notre discipline interne se superpose proprement aux quatre fonctions.
Ce que cela nous apporte : chaque projet est auditable de bout en bout au regard d'un cadre externe, et pas seulement de nos propres habitudes. Lorsqu'une équipe achats demande comment le périmètre de la phase pilote est décidé, la réponse est la même que celle que donnerait le NIST pour la gestion des risques — et l'équipe conformité du client a déjà intériorisé ce vocabulaire.
Règle 4 : enregistrable, recouvrable, recréable
La quatrième règle précède le vocabulaire de piste d'audit que nous utilisons aujourd'hui pour AI Suite. Chaque engagement de Software Tailor se déroule dans un état où toute décision, tout artefact, toute version du code peut être recréé à partir d'entrées versionnées. Ce n'est pas inhabituel pour l'ingénierie logicielle en général ; ce qui l'est, c'est que nous l'appliquons au projet, et pas seulement à la base de code. Décisions de sprint, changements de périmètre, validations client — tout est enregistré, tout est recouvrable.
Cette discipline est la raison pour laquelle notre approche des journaux d'audit sans contenu pour AI Suite a pris la forme qu'elle a. Le schéma de la ligne d'audit est le même que celui que nous appliquions déjà aux projets. Le vocabulaire est emprunté aux cadres de conformité ; la pratique est empruntée à notre manière de livrer.
Ce qui s'est transmis à AI Suite
La gamme Local AI Suite + AI Admin Console — voir Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud — est la même discipline d'ingénierie appliquée à une gamme de produits plutôt qu'à une mission sur mesure. Même modèle de livraison unique (des installateurs de bureau que le client exécute dans son propre environnement), même discipline de cohorte de clients (secteurs réglementés avec des contraintes claires de résidence des données), même correspondance aux cadres (obligations du déployeur NIST AI RMF + EU AI Act), même posture d'audit enregistrable-récupérable-recréable.
Zéro échec de projet depuis 2007 n'est pas un slogan. C'est le résultat d'un petit nombre de règles appliquées sans exception. Les mêmes règles gouvernent désormais la manière dont AI Suite est construit.
Références
- NIST. « AI Risk Management Framework (AI RMF 1.0). » nist.gov/itl/ai-risk-management-framework. Consulté le 2026-07-15.
Articles connexes
Testez la même discipline sur une charge de travail réelle.
La plateforme d'IA on-premises repose sur les mêmes règles qui ont produit ce bilan — enregistrable, récupérable, recréable, appliquées sans exception. Déployez-la sur une charge de travail réelle dans votre propre environnement et tenez-la au même standard.