J'ai fondé Software Tailor en 2006. Dix-neuf ans plus tard, l'entreprise a traversé quatre cycles économiques distincts, travaillé avec six clients du Fortune Global 500 dans les secteurs pharmaceutique, financier, gouvernemental, juridique, de la défense et de l'énergie, et n'a enregistré aucun échec de projet depuis 2007. Ce dernier chiffre est celui que les investisseurs et les responsables des achats demandent le plus souvent, et c'est le seul qui nécessite une explication. Voici les quatre règles d'ingénierie qui expliquent ce record.

Règle 1 : Un seul modèle de livraison, sans confusion entre service et produit

Chaque projet Software Tailor suit le même modèle de livraison — une phase pilote strictement définie qui livre un logiciel fonctionnel, suivie d'une extension que le client choisit de financer (ou non) en fonction de ce qui a été livré. Nous ne gérons pas une pratique « services » distincte qui livre selon des cahiers des charges, ni une pratique « produit » distincte qui livre selon des feuilles de route. Ces deux approches seraient conflictuelles ; l'une subventionnerait toujours l'autre.

Ce modèle unique signifie que chaque ingénieur sait à quoi ressemble le « terminé » avant de commencer. C'est la condition préalable pour ne pas échouer.

Règle 2 : Discipline de la cohorte client — uniquement des clients pour lesquels nous pouvons livrer

Notre cohorte de clients est sélectionnée — pas opportuniste. Six clients du Fortune Global 500 en 19 ans ne signifient pas un pipeline de ventes lent ; c'est un seuil de sélection délibéré. Chaque client que nous acceptons doit passer trois tests avant le démarrage : 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 couche 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 depuis 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 correspondaient au même schéma : 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 des infrastructures critiques d'avril 2026 [1] l'a étendu aux industries réglementées. En lisant ces documents, notre discipline interne s'aligne parfaitement sur ces quatre fonctions.

Ce que cela nous apporte : chaque projet est auditable de bout en bout selon un cadre externe, pas seulement selon nos propres habitudes. Lorsqu'une équipe d'achats demande comment la portée de la phase pilote est décidée, 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égré ce vocabulaire.

Règle 4 : Enregistrable, récupérable, recréable

La quatrième règle précède le vocabulaire de piste d'audit que nous utilisons désormais pour AI Suite. Chaque projet Software Tailor fonctionne dans un état où toute décision, tout artefact, toute version du code peut être recréée à partir d'entrées sous contrôle de version. Ce n'est pas inhabituel en ingénierie logicielle en général ; ce qui est inhabituel, c'est que nous l'appliquons au projet, pas seulement la base de code. Les décisions de sprint, les changements de périmètre, les validations clients — tout est enregistré, tout est récupérable.

Cette rigueur est la raison pour laquelle notre journaux d'audit sans contenu approche pour AI Suite a été livrée telle quelle. Le modèle de ligne d'audit est le même modèle que nous avons déjà appliqué aux projets. Le vocabulaire est emprunté aux cadres de conformité ; la pratique est empruntée à notre manière de livrer.

Ce qui s'est maintenu dans 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 personnalisée. Même modèle de livraison unique (installateurs desktop avec un pilote gratuit d'une semaine), même discipline de cohorte client (secteurs réglementés avec contraintes claires de résidence des données), même cartographie de cadre (NIST AI RMF + obligations de déploiement du EU AI Act), même posture d'audit enregistrable-récupérable-recréable.

Aucun échec de projet depuis 2007 n'est un slogan. C'est le résultat d'un petit nombre de règles appliquées sans exception. Ces mêmes règles gouvernent désormais la construction d'AI Suite.

Références

  1. NIST. « AI Risk Management Framework (AI RMF 1.0). » https://www.nist.gov/itl/ai-risk-management-framework. Consulté le 15-07-2026.