Pourquoi les outils internes d'entreprise coûtent-ils 3 fois plus que prévu?
Mardi. Mars 2019, aux alentours de 16 h. J'étais assis dans une salle de conférence au siège social de Saputo à Montréal (une entreprise de 17 milliards de dollars, environ 20 000 employés répartis dans plus de 60 usines) et je regardais une gestionnaire de projet présenter un état d'avancement sur un outil logistique interne. Vert partout. Dans les temps. Dans le budget. Trois mois plus tard, ce même outil serait mis au rancart, dix-huit mois de développement jetés à la poubelle, parce que l'équipe de l'entrepôt à Boucherville n'avait jamais été consultée sur le processus de préparation de commandes et le système qu'on avait bâti ne pouvait tout simplement pas gérer la réalité du plancher. Dix-huit mois. Disparus.
Le projet n'a pas échoué à cause du code ou des développeurs. Pantoute. Il a échoué parce que les exigences de trois départements différents (opérations, TI, gestion d'entrepôt) avaient été capturées dans trois documents séparés par trois analystes qui n'ont jamais comparé leurs notes. Les contradictions étaient invisibles jusqu'à ce que l'outil arrive entre les mains de vrais utilisateurs sur un vrai plancher d'entrepôt.
J'ai vu ce pattern-là peut-être une centaine de fois en 25 ans de livraison en entreprise. L'outil fonctionne parfaitement pour le département qui l'a spécifié. Complètement. Mais les quatre autres départements qui ont besoin de l'utiliser? Personne leur a posé les bonnes questions au bon moment, et quand quelqu'un finit par le faire, l'architecture peut pas accommoder ce dont ils ont besoin sans une refonte majeure. C'est ça, le multiplicateur de coût 3x : on le bâtit une fois pour un département, puis on le reconstruit deux autres fois en essayant de le faire marcher pour tout le monde.
La cause fondamentale, c'est pas la paresse ou le manque de processus. C'est structurel. Les organisations d'entreprise sont assez grosses pour que les gens qui connaissent le vrai processus (Nathalie sur le plancher de l'entrepôt, la commis aux comptes payables qui a un contournement pour le module SAP brisé, le directeur régional qui suit l'inventaire dans un tableur personnel) ne se retrouvent jamais dans la même pièce que les gens qui écrivent les exigences. Specira existe pour combler cet écart.
Qu'est-ce qui rend l'alignement des exigences inter-départements si difficile?
Le vocabulaire. Sérieusement. C'est là que ça commence. Les finances appellent ça un « client ». Les ventes appellent la même entité un « compte ». Les opérations appellent ça un « site ». Tout le monde parle de la même chose, à peu près, mais la définition de chaque département transporte des champs de données différents, des relations différentes, des règles d'affaires différentes. J'ai vu un atelier d'exigences de 14 personnes chez Quebecor Retail s'effondrer dans un débat de 40 minutes sur ce que « client actif » voulait dire, et quand la poussière est retombée, il y avait quatre définitions compétitives, toutes techniquement correctes dans leur département respectif.
Mais le vocabulaire, c'est juste la surface. Le problème plus profond, c'est que chaque département a optimisé son flux de travail de façon indépendante pendant des années, parfois des décennies, et ces optimisations entrent en conflit les unes avec les autres d'une manière que personne remarque tant qu'on n'essaie pas de bâtir un système partagé. Les opérations veulent du traitement par lots la nuit parce que c'est quand leurs systèmes sont au repos. Les finances ont besoin de données en temps réel parce que la clôture de fin de mois peut pas attendre les traitements batch. Les TI veulent un point d'intégration unique pour la sécurité. Chaque demande est raisonnable en isolation. Ensemble, elles sont architecturalement incompatibles sans des décisions de compromis explicites.
Bon, voici ce que la plupart des firmes de consultation vont pas vous dire (et je dis ça en ayant travaillé aux côtés de plusieurs des grandes) : l'approche traditionnelle de tenir des ateliers avec les parties prenantes, écrire un document d'exigences consolidé et obtenir une approbation, ça marche pas pour l'alignement inter-départements. Pas vraiment. Ça produit un document que tout le monde accepte parce que personne le lit assez attentivement pour repérer les contradictions enfouies à la page 47. Ensuite le développement débute, les contradictions remontent durant les tests, et la guerre de blâme commence.
Ce qui marche à la place? Un système qui peut tenir les exigences de chaque partie prenante simultanément et faire ressortir les conflits automatiquement. Pas après que le document est signé, pas durant les tests d'acceptation, mais pendant la conversation elle-même. C'est ce que fait Specira AI, et honnêtement, c'est la raison pour laquelle j'ai fondé la compagnie. Après avoir vu ce mode d'échec exact se reproduire chez Saputo, chez Quebecor, dans une douzaine d'autres organisations, je savais que le problème, c'était pas les gens. C'était les outils qu'on utilisait pour capturer ce que les gens disaient.
Qu'est-ce qu'un engagement entreprise Specira inclut?
Chaque entreprise est différente. Évidemment. Un fabricant de 200 personnes a rien en commun avec une firme de services financiers de 5 000 employés, sauf le fait que les deux ont des départements qui se parlent pas. Mais la structure de l'engagement suit un pattern que j'ai raffiné à travers des mandats dans des entreprises allant de 50 à 20 000 employés. Voici ce qu'on obtient :
Phase 1 : Découverte inter-départements (3 à 5 semaines)
C'est la phase que la plupart des organisations bâclent. Nous, on la bâcle pas. Chaque département concerné par le système a des sessions dédiées avec Specira AI, guidées par Nicolas Payette personnellement. L'IA capture les exigences dans un modèle structuré (pas un document Word) et croise chaque exigence avec celles de chaque autre département en temps réel. À la fin de cette phase, on a une spécification validée où chaque conflit inter-département a été identifié et résolu. Pas caché. Résolu.
Phase 2 : Architecture et cartographie des intégrations (2 à 3 semaines)
Les applications d'entreprise vivent pas en isolation. Elles se connectent à des systèmes ERP, des plateformes CRM, des entrepôts de données, des fournisseurs d'identité, des bases de données patrimoniales que personne comprend plus complètement. Cette phase cartographie chaque point d'intégration, définit les contrats d'API, et documente le flux de données entre les systèmes. Si une dépendance est fragile (et dans les environnements d'entreprise, il y en a toujours au moins une), on le sait avant que le code débute, pas quand un déploiement en production plante à 2 h du matin.
Phase 3 : Fondation et construction du noyau (4 à 8 semaines)
Authentification (habituellement intégrée avec Active Directory ou Okta), contrôle d'accès par rôle, journaux d'audit, la couche de données centrale, le pipeline CI/CD et la surveillance. Cette fondation gère les préoccupations spécifiques à l'entreprise que les frameworks SaaS génériques adressent pas : permissions granulaires, pistes d'audit de conformité, contraintes de résidence de données et déploiement multi-environnements. On voit un environnement de staging avec de la vraie infrastructure et de vraies intégrations à la fin de cette phase.
Phase 4 : Sprints de fonctionnalités (8 à 16 semaines)
Des sprints de deux semaines bâtis sur la feuille de route priorisée de la Phase 1. Chaque sprint produit un incrément déployable. Les parties prenantes de chaque département assistent aux démos de sprint et donnent du feedback par rapport au modèle d'exigences validé, fait que le scope creep se fait prendre immédiatement. Nicolas révise chaque pull request, chaque décision architecturale, chaque démo de sprint. C'est pas délégué à un coordonnateur de projet que vous avez jamais rencontré.
Phase 5 : Déploiement et adoption (2 à 4 semaines)
Les applications d'entreprise ont besoin d'une stratégie de déploiement : groupes pilotes, déploiement par phases, soutien à la gestion du changement, matériel de formation, exécution de la migration de données et périodes de fonctionnement en parallèle. Cette phase couvre tout ça, parce que lancer un outil d'entreprise sans planification de l'adoption, c'est comme ça qu'on se retrouve avec un système parfaitement fonctionnel que personne utilise.
À retenir
Un engagement entreprise Specira est structuré autour des défis spécifiques des organisations multi-départements : exigences contradictoires, intégrations complexes, contraintes de conformité et résistance à l'adoption.
- 3 à 5 semaines de découverte inter-départements (pas un seul atelier de lancement)
- Chaque intégration cartographiée et contractée avant que le code commence
- Livraison menée par le fondateur avec des démos aux parties prenantes aux deux semaines
- Planification du déploiement incluse, pas traitée comme le problème de quelqu'un d'autre
Comment le développement entreprise de Specira se compare
| Aspect | Intégrateur de systèmes typique | Approche Specira |
|---|---|---|
| Découverte | Atelier de 2 jours avec les parties prenantes | 3 à 5 semaines de sessions inter-départements structurées avec validation par l'IA |
| Exigences | Document Word de 200 pages que personne lit | Modèle structuré avec détection automatisée des conflits |
| Planification des intégrations | Découverte pendant le développement | Cartographiée et contractée en Phase 2 avant le code |
| Leadership | Consultants rotatifs et sous-traitants | Nicolas Payette mène chaque engagement personnellement |
| Conflits inter-départements | Remontent pendant les tests d'acceptation (trop tard) | Identifiés et résolus pendant la découverte (Phase 1) |
| Adoption | « Ça, c'est la gestion du changement, pas notre mandat » | Stratégie de déploiement et formation incluses |
Comment fonctionne le processus de développement pour les équipes d'entreprise?
Le courriel est arrivé un vendredi après-midi, parce que c'est toujours un vendredi après-midi que les mauvaises nouvelles arrivent. « On a besoin d'un portail unifié pour les opérations terrain, et le conseil veut que ce soit en production pour le Q3. » Dix-neuf mots. C'était le brief. Derrière ces dix-neuf mots, il y avait huit départements, trois systèmes patrimoniaux, deux fuseaux horaires et environ 340 personnes qui auraient éventuellement besoin d'utiliser l'affaire. Bienvenue dans le développement d'entreprise.
Semaines 1 à 2 : Cartographie des parties prenantes et prise en charge. Avant que quiconque parle de fonctionnalités, on cartographie le paysage organisationnel : qui possède quelles données, qui prend les décisions, qui a un droit de veto, et (point critique) qui sont les experts informels dont les connaissances vivent nulle part sauf dans leur tête. Chez Saputo, la personne qui comprenait réellement comment les transferts inter-usines fonctionnaient, c'était pas une gestionnaire. C'était une coordonnatrice logistique nommée Marie-Claire qui faisait la job depuis 22 ans et qui n'avait jamais été invitée à une seule session de planification TI.
Semaines 3 à 5 : Capture des exigences validées par l'IA. Département par département, chaque groupe de parties prenantes travaille avec Specira AI pour articuler ses besoins. L'IA bâtit le modèle d'exigences de façon incrémentale, signalant les conflits en temps réel. « Les opérations veulent de la synchronisation par lots nocturne, mais les finances ont besoin d'allocation de coûts en temps réel. Ces exigences sont incompatibles à moins qu'on ajoute un pipeline de données en continu. » Ces conflits se règlent là, en conversation. Pas six mois plus tard dans un rapport de défaut.
Semaines 6 à 8 : Architecture, cartographie des intégrations et fondation. On conçoit l'architecture du système autour des exigences validées et des contraintes de l'entreprise (sécurité, conformité, infrastructure existante). Les contrats d'intégration sont définis avec de vraies spécifications d'API, pas des énoncés vagues sur « se connecter à SAP ». L'infrastructure de fondation se déploie en staging.
Semaines 9 à 24 : Sprints de fonctionnalités avec démos aux parties prenantes. Des cycles de deux semaines, des incréments déployables, du feedback direct des représentants de départements. Le modèle d'exigences validé sert de source de vérité, fait que quand quelqu'un dit « c'est pas ce que j'avais demandé », on peut pointer vers la conversation exacte où la décision a été prise et pourquoi.
Semaines 25 à 28 : Déploiement pilote, formation et mise en production complète. Le système va à un groupe pilote d'abord, typiquement 20 à 50 utilisateurs du département le plus critique. Les problèmes remontent dans un environnement contrôlé. Ensuite, déploiement par phases à travers les départements restants avec des ressources de soutien en place.
Échéancier total? À peu près 20 à 28 semaines pour une application d'entreprise de complexité moyenne. C'est rapide pour de l'entreprise. La vitesse vient du fait qu'on découvre pas les problèmes d'exigences au mois huit du développement.
Comment Specira AI aligne-t-elle les exigences à travers des centaines de parties prenantes?
Trois cent quarante parties prenantes. C'est le nombre de personnes qui avaient une voix légitime dans le portail d'opérations terrain dont j'ai parlé plus tôt. Pas toutes ont participé aux sessions d'exigences, évidemment. Mais environ 60 l'ont fait, représentant huit départements, et chacune a amené un modèle mental de comment le système devrait fonctionner qui était subtilement (et parfois dramatiquement) différent de celui de tout le monde.
Specira AI gère ça en bâtissant un modèle d'exigences multi-perspectives. Pas un document qui essaie d'être tout pour tout le monde, mais une représentation structurée de ce que chaque groupe de parties prenantes a besoin, où ces besoins s'alignent, et où ils entrent en conflit. Le modèle grandit avec chaque conversation, et l'IA roule des passes de validation de façon continue. Pas à la fin d'une phase d'exigences de trois mois. De façon continue.
La détection de conflits, c'est la capacité centrale. Quand l'équipe de l'entrepôt dit « on doit fermer les fenêtres de réception à 15 h » et l'équipe d'approvisionnement dit « les fournisseurs peuvent livrer jusqu'à 17 h », cette contradiction est signalée immédiatement. Pas comme un item dans un registre de risques que personne lit, mais comme un point de conversation actif : « Ces deux exigences se contredisent. Voici trois résolutions possibles, avec les compromis pour chaque département. »
La stratégie d'outils internes de Spotify : Quand Spotify a bâti Backstage, leur portail développeur interne, un des plus gros défis était d'aligner les exigences à travers environ 300 équipes d'ingénierie autonomes. Chaque équipe avait son propre flux de travail, ses propres outils, sa propre définition de « prêt pour la production ». L'équipe Backstage a résolu ça en créant une architecture à modules extensibles où les besoins spécifiques de chaque équipe pouvaient être accommodés sans briser la plateforme commune. Le résultat : un outil interne qui est passé d'un projet d'équipe à une plateforme open source maintenant utilisée par des centaines d'entreprises.
La plupart des outils internes d'entreprise ont pas cette clairvoyance architecturale. On bâtit pour le flux de travail d'un département et on découvre trop tard que les sept autres départements ont besoin de quelque chose de fondamentalement différent. C'est le problème que les exigences validées par l'IA règlent : faire remonter ces différences avant que l'architecture s'engage envers une seule perspective.
Le modèle traque aussi les dépendances implicites. Chaque entreprise en a. Les finances ont besoin d'un champ que seul l'entrepôt remplit. Le tableau de bord exécutif a besoin d'un indicateur qui dépend de données provenant de cinq systèmes sources différents. Ces dépendances sont invisibles dans les documents d'exigences traditionnels parce qu'elles traversent les frontières départementales, et personne est propriétaire de la vue transversale. L'IA en est propriétaire. Chaque exigence est mappée à ses dépendances de données, ses points de contact d'intégration et ses consommateurs en aval. Quand quelqu'un change une exigence au mois trois, l'IA montre exactement ce qui est affecté à travers chaque département.
Est-ce que ça remplace le jugement humain? Non. En fait, je veux faire attention à pas trop promettre ici. Ce que ça remplace, c'est l'hypothèse que les humains peuvent garder en mémoire de travail cent perspectives de parties prenantes simultanément et repérer chaque conflit entre elles. On est pas capables. J'ai fait ça pendant 25 ans, et je manque encore des choses. L'IA manque pas les conflits structurels. Elle manque les nuances, le contexte, la politique organisationnelle. Fait qu'on a besoin des deux : l'IA pour le croisement exhaustif, l'humain (moi, dans ce cas) pour interpréter ce que les conflits veulent dire et guider les conversations de résolution.
Ce chiffre, 4,4 millions de dollars, c'est la moyenne. Pour les grands projets d'entreprise dans des organisations de milliers d'employés, le montant est pas mal plus élevé. Et le coût est pas juste financier. Les outils internes échoués érodent la confiance entre les TI et les départements d'affaires, ce qui rend le prochain projet encore plus difficile à financer. J'ai vu des organisations entrer dans une spirale de déclin où chaque projet échoué réduit le budget et la bonne volonté disponibles pour le suivant, jusqu'à ce que la seule option qui reste soit d'acheter un outil clé en main qui convient au flux de travail de personne mais qui porte au moins pas le stigma d'un autre projet sur mesure qui a échoué.
L'approche de Specira brise ce cycle en rendant la phase la plus risquée du développement d'entreprise (les exigences et l'alignement) dramatiquement plus fiable. Pas parfaite. Je prétendrai jamais parfaite. Mais assez fiable pour que l'architecture reflète ce dont l'organisation a réellement besoin, pas ce qu'un département a supposé pendant que tout le monde était dans un autre meeting.
Quelles sont les questions les plus courantes sur le développement d'entreprise avec Specira?
