Un guide pour les directions métier en ETI : achats, opérations, finance, logistique. Pour ceux dont le projet d'outil vient d'être refusé, reporté ou enterré dans le backlog de la DSI, et qui veulent livrer quand même. Sans passer en force.
La scène est toujours la même. Votre équipe perd des heures chaque semaine sur un process qui tourne sur Excel, des exports croisés et des ressaisies. Vous avez trouvé une solution, parfois même un prestataire. Vous présentez le projet. Et la DSI répond non. Ou pire : « on le met au plan de charge », ce qui, sans sponsor, veut souvent dire jamais.
Le réflexe naturel est d'y voir de l'obstruction. C'est presque toujours une erreur de lecture. Ce que la DSI refuse, ce n'est pas votre besoin : c'est un risque qu'elle ne peut pas garantir en l'état du dossier. La distinction change tout, parce qu'un besoin refusé se contourne, alors qu'un risque identifié se traite.
Avant de convaincre une DSI, il faut comprendre ce qu'elle voit quand votre projet arrive sur son bureau. Cinq risques structurent sa lecture.
Un outil qui touche vos données clients ou fournisseurs, hébergé on ne sait où, avec des comptes créés à la main, c'est exactement ce que la PSSI existe pour empêcher. La DSI ne sait pas ce que vaut le prestataire, où partent les données, qui a accès à quoi. Tant que ces questions restent ouvertes, elle répond non.
Un freelance qui change de vie, une petite agence qui ferme, un SaaS early stage racheté : la DSI a déjà vu ces scénarios. Si l'outil devient critique et que personne ne peut le reprendre, c'est elle qui héritera du problème. Sans réversibilité démontrée, le non est rationnel.
Chaque outil isolé crée sa propre version de la vérité : des clients en double, des référentiels qui divergent, des exports qui se contredisent. La DSI passe déjà une partie de son temps à réconcilier des données. Un outil qui ne parle ni à l'ERP ni à l'annuaire aggrave le problème qu'il prétend régler.
Le build est l'épisode court. Ensuite viennent les mises à jour de sécurité, les montées de version, les sauvegardes, les incidents, les demandes d'évolution. Si personne n'a budgété ni désigné qui opère l'outil, la DSI sait que ça finira dans son backlog. Qui est déjà plein.
Le fichier Access devenu critique dont l'auteur est parti. La macro construite par un stagiaire qui pilote la facturation. L'abonnement SaaS découvert au moment de l'audit. La plupart des DSI ont leur musée du shadow IT, et chaque pièce du musée a coûté cher. Votre projet est jugé à la lumière de ces précédents.
Remarquez ce que cette liste ne contient pas : « votre besoin n'est pas important ». Une DSI sérieuse sait que le process qui tourne sur Excel est un problème. Elle refuse la solution proposée, pas le problème à résoudre.
Face au blocage, trois contournements reviennent sans cesse. Les trois produisent le plus souvent le même résultat, avec des délais différents.
Un abonnement souscrit sur le budget du service, sans contrat cadre, avec un DPA standard que personne n'a lu, hors du registre des traitements, et des données clients dedans. Invisible jusqu'au premier incident ou au premier audit RGPD. Ensuite, très visible.
Un outil monté en interne sur une plateforme choisie pour sa facilité, pas pour sa conformité. Il marche, il grossit, il devient critique. Personne ne l'a architecturé, personne ne sait en extraire les données ni le reconstruire ailleurs.
Le moins cher à court terme, le plus cher à long terme. Un outil sans tests, sans documentation, sans gestion des accès, dont l'auteur part dans 12 mois. La DSI le sait avant même que le projet commence.
Cause
L'outil marche
L'équipe s'en sert. Hors du cadre, mais il rend service.
Conséquence
Il devient critique
Personne ne l'opère, ne le sauvegarde, ne le surveille.
Résultat
Incident de production
Le sujet remonte à la DSI. Avec votre nom dessus.
Le shadow IT ne supprime pas le risque : il le déplace vers vous, en y ajoutant des intérêts.
La méthode tient en une phrase : arrivez avec les réponses aux questions que la DSI posera de toute façon. Première étape, demandez les raisons précises du refus, par écrit : sécurité, hébergement, réversibilité, charge de run. Chaque raison a sa contre-mesure dans le tableau qui suit.
| Ne pas faire | Faire |
|---|---|
| Présenter un projet déjà ficelé, prestataire signé, à valider en urgence. | Impliquer la DSI au cadrage : elle choisit les contraintes, elle s'approprie le projet. |
| Souscrire un hébergement inconnu avec la carte bleue du service. | Un hébergement conforme à la politique interne : cloud référencé par la DSI ou on-premise. |
| Des comptes locaux créés à la main, outil par outil. | L'authentification sur l'annuaire de l'entreprise (SSO, Entra ID). |
| Le code et les accès qui restent chez le prestataire. | Vous êtes propriétaire du code, le dépôt est chez vous dès le premier jour. |
| « On documentera à la fin. » | La documentation d'architecture et d'exploitation en livrable contractuel. |
| Un framework maison ou une plateforme exotique que seul l'auteur maîtrise. | Une stack standard et répandue : n'importe quelle équipe peut reprendre. |
| Livrer, puis voir plus tard qui s'en occupe. | Le run désigné et budgété d'entrée : qui opère, qui corrige, qui fait évoluer. |
| Découvrir le questionnaire sécurité après la signature du devis. | Le dossier fournisseur prêt : RC pro, NDA, DPA, réponses au questionnaire. |
Mis en forme, le dossier reste court, une page ou deux :
Projet : outil métier
6 rubriques
Avis DSI : à recueillir au cadrage, pas à la recette.
Présenté comme ça, le rapport de force s'inverse. Vous ne demandez plus une faveur : vous apportez un projet déjà aligné sur la PSSI, sans silo ni run non budgété. La DSI passe de gardienne à sponsor : votre projet devient une vitrine de ce qu'elle essaie d'obtenir de tous les métiers.
Le choix du prestataire fait l'essentiel de votre dossier. C'est lui qui apporte, ou pas, les garanties que la DSI attend. Trois options se présentent en pratique.
| Critère | ESN classique | No-code hors DSI | Senior compatible DSI |
|---|---|---|---|
| Passage du comité sécurité | Oui, c'est leur terrain | Rarement : hébergement et accès non maîtrisés | Oui, conçu pour |
| Délai de livraison | Souvent en mois, cycle projet oblige | Se compte en jours | Se compte en semaines |
| Budget type | Souvent à six chiffres, régie ou forfait épais | Quelques centaines d'euros par mois, puis dérive | À partir de 10 K€, forfait à périmètre fixe |
| Réversibilité | Variable, souvent verrouillée au contrat | Faible : plateforme propriétaire | Contractuelle : code, doc, stack standard |
L'ESN passera le comité sécurité, mais vous paierez sa structure et son rythme. Le no-code grand public, souscrit hors du SI, livrera vite mais restera hors du cadre. Le freelance IA-first livre du code, parfois excellent, mais passe rarement l'examen du RSSI : hébergement improvisé, pas de dossier fournisseur, réversibilité jamais contractualisée. La troisième voie combine vitesse et cadre : un profil senior, outillé par l'IA pour livrer en semaines, et qui connaît les codes du référencement fournisseur pour que la vitesse ne se paie pas en conformité. Avant de vous engager, vérifiez ces points.
Le non de votre DSI est un non au risque, pas à votre besoin. Contourner ce non par le shadow IT déplace le risque vers vous et le fait grossir. Le chemin le plus rapide vers la production passe par un dossier qui traite les cinq raisons du blocage, un cadrage où la DSI est impliquée dès le début, et un prestataire capable de livrer vite dans son cadre. C'est plus exigeant qu'une carte bleue. C'est aussi le seul chemin qui ne revient pas vous hanter.
Huit termes qui reviennent dans toute discussion avec une DSI. Les maîtriser, c'est déjà la moitié du dossier.
Parce qu'elle est responsable de ce qui se passe après. Un outil non validé peut exposer des données, créer un silo, devenir critique sans que personne ne l'opère. Le non porte sur le risque en l'état du dossier, pas sur la légitimité du besoin. La plupart des refus sont des « pas comme ça » plutôt que des « jamais ».
Demander les raisons précises du blocage, par écrit si possible : sécurité, hébergement, réversibilité, charge de run. Chaque raison a une réponse concrète. Puis revenir avec un dossier qui les traite une par une, en impliquant la DSI au cadrage. Ce qui ne marche pas : passer en force avec un abonnement SaaS ou un développement caché.
En arrivant avec ce qu'elle demanderait de toute façon : hébergement conforme à la politique interne, authentification sur l'annuaire, propriété du code, documentation livrée, run désigné et budgété. Une DSI passe du non au oui quand le dossier lui prouve qu'elle ne paiera pas le projet plus tard. Le choix du prestataire fait l'essentiel de cette démonstration.
Oui, mais pas là où on le croit. Le risque n'est pas l'outil lui-même, c'est son cycle de vie : des données réelles dans un service que personne n'a évalué, des accès que personne ne gouverne, des sauvegardes que personne n'a vérifiées, et une criticité qui grandit en silence. Le jour où l'outil casse ou fuit, le coût retombe sur la DSI et sur la direction métier qui l'a introduit. Le risque ne disparaît jamais : il change simplement de porteur. Vous.
C'est le processus de validation d'un nouveau prestataire : dossier administratif, contrat avec clauses de propriété et de réversibilité, questionnaire sécurité. Un prestataire qui a l'habitude arrive avec le dossier prêt et répond au questionnaire point par point : de son côté, aucun jour de perdu. Le délai restant dépend de votre circuit interne (comité, achats, juridique), pas du prestataire. Le détail de ce que je fournis est décrit sur ma page dédiée aux ETI.
Alors le sujet n'est plus technique, il est politique : arbitrage de priorités, de budget ou de calendrier. Dans ce cas, chiffrez le coût du statu quo (heures perdues par semaine, erreurs, retards clients) et portez l'arbitrage au niveau DG ou COMEX, avec votre dossier et l'avis de la DSI en pièces jointes. Ce n'est pas un passage en force : c'est un arbitrage documenté entre deux risques. Et souvent, ce non-là signifie « pas ce trimestre » : un projet propre et prêt est le premier servi quand une fenêtre s'ouvre.
Techniquement oui, et c'est presque toujours une erreur. Tant que l'outil manipule des données de test et ne sert qu'à prototyper, personne ne s'en soucie. Dès qu'il touche des données réelles ou qu'une équipe en dépend, chaque jour hors du cadre augmente la dette et le coût de la régularisation. La voie rapide n'est pas de contourner la DSI, c'est de lui apporter un dossier qu'elle peut valider vite.
Chez moi : un build au forfait démarre à 10 000 € HT, la plupart des outils métier se situent entre 15 et 40 K€ selon le périmètre. L'intégration au SI (SSO, hébergement validé, documentation) est comprise dans le forfait, pas facturée en option. Pour un accompagnement récurrent, le CTO-as-a-Service démarre à 2 900 € HT par mois, ajusté à l'intensité de la mission.
Pour aller plus loin : pourquoi l'IA ne consolidera jamais vos fichiers Excel (le cas d'école du process achats), et votre outil métier en 15 jours : mythe ou réalité pour la partie build.