Votre équipe perd des heures chaque semaine sur un process qui tourne sur Excel, des exports croisés et des ressaisies. La scène est toujours la même. 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.
Pourquoi votre DSI bloque votre projet, et pourquoi c'est rationnel
Votre DSI ne refuse pas votre besoin : elle refuse un risque qu'elle ne peut pas garantir en l'état du dossier. Y voir de l'obstruction est le réflexe naturel, et presque toujours une erreur de lecture. La distinction change tout, parce qu'un besoin refusé se contourne, alors qu'un risque identifié se traite.
Les 5 raisons pour lesquelles une DSI refuse un outil métier
Avant de convaincre votre DSI, regardez ce qu'elle voit quand votre projet arrive sur son bureau. Sa lecture tient en 5 risques.
La sécurité : un outil non validé est une surface d'attaque
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 votre politique de sécurité existe pour empêcher. Ce document cadre fixe les règles de l'entreprise : hébergement autorisé, gestion des accès, exigences sur les prestataires. Quand il n'est pas formalisé, ses exigences existent quand même, dans la tête du DSI. 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.
La réversibilité : qui reprend l'outil si le prestataire disparaît ?
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, c'est-à-dire la capacité à reprendre l'outil sans son prestataire d'origine, le non est rationnel. Elle se conçoit au début du projet et se vérifie au contrat, pas au moment du divorce.
Le silo : une base de données de plus, déconnectée du SI
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 run : un outil livré se maintient pendant des années
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.
Les cicatrices : votre DSI a déjà vécu le scénario
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, ces outils utilisés dans l'entreprise sans sa validation, et chaque pièce du musée a coûté cher. Votre projet est jugé à la lumière de ces précédents.
Votre besoin n'est jamais en cause dans cette liste : aucune de ces raisons ne dit qu'il 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.
Shadow IT : la fausse bonne solution
Face au blocage de votre DSI, 3 contournements reviennent sans cesse. Tous les 3 produisent le plus souvent le même résultat, avec des délais différents.
Le SaaS à la carte bleue
Un abonnement souscrit sur le budget du service, sans contrat cadre, avec un contrat de sous-traitance des données 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.
Le no-code sauvage
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.
L'alternant qui code
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.
Convaincre sa DSI : le dossier qui obtient un oui
Arrivez avec les réponses aux questions que la DSI posera de toute façon : la méthode tient en une phrase. 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 les 8 lignes qui suivent.
- Ne pas faire : Présenter un projet déjà ficelé, prestataire signé, à valider en urgence.Faire : Impliquer la DSI au cadrage : elle choisit les contraintes, elle s'approprie le projet.
- Ne pas faire : Souscrire un hébergement inconnu avec la carte bleue du service.Faire : Un hébergement conforme à la politique interne : cloud référencé par la DSI ou on-premise.
- Ne pas faire : Des comptes locaux créés à la main, outil par outil, que plus personne ne révoque.Faire : L'authentification unique sur l'annuaire de l'entreprise (SSO, Entra ID) : un collaborateur qui part perd d'un coup l'accès à tous les outils raccordés.
- Ne pas faire : Le code et les accès qui restent chez le prestataire.Faire : Vous êtes propriétaire du code, le dépôt est chez vous dès le premier jour.
- Ne pas faire : « On documentera à la fin. »Faire : La documentation d'architecture et d'exploitation en livrable contractuel.
- Ne pas faire : Un framework maison ou une plateforme exotique que seul l'auteur maîtrise.Faire : Une stack standard et répandue : n'importe quelle équipe peut reprendre.
- Ne pas faire : Livrer, puis voir plus tard qui s'en occupe.Faire : Le run désigné et budgété d'entrée : qui opère, qui corrige, qui fait évoluer.
- Ne pas faire : Découvrir le questionnaire sécurité après la signature du devis.Faire : Le dossier fournisseur prêt : RC pro, accord de confidentialité, contrat de sous-traitance des données, réponses au questionnaire.
Mis en forme, votre dossier reste court, une page ou deux :
Projet : outil métier
6 rubriques
- 01 Le besoin, et ce qu'il coûte aujourd'hui
- 02 Le périmètre proposé
- 03 L'hébergement et les accès prévus
- 04 Le run : qui opère, sur quel budget
- 05 Les garanties de réversibilité
- 06 Le dossier fournisseur du prestataire
Avis DSI : à recueillir au cadrage, pas à la recette.
Présenté comme ça, votre dossier inverse le rapport de force. Vous ne demandez plus une faveur : vous apportez un projet déjà aligné sur votre politique de sécurité, 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.
Société de services, no-code ou prestataire compatible DSI : que choisir ?
Votre choix de prestataire fait l'essentiel du dossier. C'est lui qui apporte, ou pas, les garanties que la DSI attend. En pratique, vous avez 3 options.
Société de services informatiques classique
- Passage du comité sécurité
- Oui, c'est leur terrain
- Délai de livraison
- Souvent en mois, cycle projet oblige
- Budget type
- Souvent à 6 chiffres, régie ou forfait épais
- Réversibilité
- Variable, souvent verrouillée au contrat
No-code hors DSI
- Passage du comité sécurité
- Rarement : hébergement et accès non maîtrisés
- Délai de livraison
- Se compte en jours
- Budget type
- Quelques centaines d'euros par mois, puis dérive
- Réversibilité
- Faible : plateforme propriétaire
Senior compatible DSI
- Passage du comité sécurité
- Oui, conçu pour
- Délai de livraison
- Se compte en semaines
- Budget type
- À partir de 10 K€, forfait à périmètre fixe
- Réversibilité
- Contractuelle : code, doc, stack standard
Si vous choisissez une société de services informatiques, elle 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 de votre responsable sécurité, dans beaucoup d'ETI le DSI lui-même ou un prestataire externe : 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 les 6 points suivants :
- A déjà passé un référencement fournisseur ou un comité sécurité, et peut le raconter en détail.
- Parle politique de sécurité, SSO, contrat de sous-traitance des données et journalisation sans avoir besoin d'un traducteur.
- Livre systématiquement documenté : architecture, exploitation, décisions.
- Travaille au forfait, à périmètre fixe : pas de régie qui s'étire.
- Pose la réversibilité au contrat : propriété du code, dépôt chez vous, stack standard.
- Cherche le contact avec votre DSI dès le premier call, au lieu de l'éviter.
Auteur de l'article
Fabien Bousquet, CTO externalisé.
Pas une équipe, pas un sous-traitant. C'est moi qui vous écris, qui cadre, qui build, qui livre.
En savoir plus sur mon parcours →FAQ
Pourquoi la DSI dit-elle non aux projets des directions métier ?
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 ».
Que faire quand la DSI bloque un projet d'outil métier ?
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é.
Comment convaincre sa DSI de valider un projet ?
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.
Le shadow IT est-il vraiment un risque pour l'entreprise ?
Oui, mais pas là où on le croit. Le shadow IT naît d'un vrai besoin métier resté sans réponse. 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.
Qu'est-ce que le référencement fournisseur, et comment le passer ?
C'est le processus par lequel une ETI ou un grand groupe valide un nouveau prestataire : dossier administratif, contrat avec clauses de propriété et de réversibilité, questionnaire sécurité, parfois un audit. Comptez de quelques semaines à quelques mois selon l'organisation. 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 qui est fourni chez moi est décrit sur la page dédiée aux ETI.
Et si la DSI dit encore non, malgré un bon dossier ?
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 comité exécutif, 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 2 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.
Quel contrat sur les données personnelles la DSI attend-elle ?
Le contrat de sous-traitance des données, exigé par le RGPD dès qu'un prestataire traite des données personnelles pour votre compte. Son absence est un signal d'alerte immédiat pour une DSI. Celui qui porte le RGPD chez vous, le délégué à la protection des données, veille à ce que ce contrat soit en place. Il est aussi consulté sur la localisation des données personnelles et leurs durées de conservation.
Peut-on développer un outil métier sans passer par la DSI ?
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.
Combien coûte un outil métier compatible DSI ?
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 : Shadow AI : vos équipes utilisent déjà ChatGPT avec vos données (la même mécanique, côté IA générative), et pourquoi l'IA ne consolidera jamais vos fichiers Excel (le cas d'école du process achats). Pour la partie build, lisez votre outil métier en 15 jours : mythe ou réalité. Si l'outil existe déjà et que le prestataire décroche, voir la reprise de projet informatique.