Une étude publiée le 23 juillet 2026 apporte un éclairage utile aux PME qui lancent un projet numérique sans direction informatique structurée. À partir de six petites entreprises de services, les chercheurs concluent que les moyens techniques et la culture d’entreprise ne produisent pas, à eux seuls, une capacité de transformation : il faut une véritable aptitude à piloter les projets. Cette étude sur la préparation numérique des petites entreprises ne constitue pas un baromètre français, mais elle rappelle une distinction essentielle : ne pas avoir de DSI ne dispense pas d’exercer temporairement la fonction de direction du projet.
La promesse qu’on entend partout : l’outil et le prestataire piloteront le projet
Le discours est séduisant. Un ERP ou un CRM en mode SaaS serait plus simple à déployer qu’un ancien logiciel installé dans l’entreprise. Une plateforme de gestion de projet centraliserait les tâches, les délais et les documents. L’intégrateur apporterait sa méthode, tandis qu’un responsable administratif, financier ou commercial coordonnerait les demandes en parallèle de son activité habituelle.
Dans cette logique, la PME n’aurait besoin ni de DSI ni de chef de projet dédié. Il suffirait de choisir une solution reconnue, de demander aux responsables métier de participer aux ateliers et de suivre l’avancement dans un tableau partagé.
Cette promesse confond pourtant trois fonctions différentes :
- l’outil, qui conserve et présente l’information ;
- le prestataire, qui conçoit, paramètre ou déploie la solution commandée ;
- le pilotage côté entreprise, qui arbitre les priorités, vérifie la valeur métier et accepte ou refuse les livrables.
Les deux premières fonctions peuvent être externalisées. La troisième reste sous la responsabilité de l’entreprise, même lorsqu’elle est confiée opérationnellement à une direction de projet externe.
Ce qui est vrai : une PME n’a pas nécessairement besoin d’une DSI permanente
Un projet IT ne justifie pas toujours le recrutement d’un directeur des systèmes d’information à temps plein. Une PME peut déployer un CRM, remplacer son ERP, migrer une application dans le cloud ou automatiser un processus sans créer immédiatement une nouvelle direction interne.
Les outils collaboratifs apportent aussi une réelle valeur. Ils rendent visibles les tâches en attente, les décisions prises, les anomalies et les responsabilités. Une méthode itérative permet de montrer rapidement des éléments fonctionnels aux utilisateurs au lieu d’attendre la fin du projet pour découvrir la solution.
Enfin, l’intégrateur possède une expertise que la PME n’a pas vocation à reconstruire pour chaque technologie. Il connaît le produit, ses contraintes de paramétrage et ses interfaces. Il peut recommander une architecture réaliste et alerter sur les demandes qui nécessiteraient un développement spécifique.
La bonne conclusion n’est donc pas qu’une DSI permanente serait obligatoire. Elle est qu’il faut dimensionner une fonction de pilotage adaptée au projet. Selon le nombre de sujets numériques à coordonner, cette fonction peut être temporaire ou s’inscrire dans une logique de DSI à temps partagé pour PME.
Ce qui est faux, ou seulement vrai sous conditions
Un tableau de bord ne prend aucune décision
Un logiciel peut afficher qu’une tâche est bloquée. Il ne peut pas décider si la direction commerciale doit renoncer à une fonctionnalité, si le budget doit être réalloué à la migration des données ou si le déploiement doit être reporté en raison d’une recette incomplète.
Chaque projet doit donc avoir un sponsor, c’est-à-dire un dirigeant disposant de l’autorité nécessaire pour arbitrer le budget, le périmètre et les priorités. À ses côtés, un pilote organise les travaux et un responsable métier vérifie que la solution répond aux usages réels. Le Project Management Institute attribue notamment au sponsor la clarification des objectifs, la définition des critères de réussite, les décisions de passage entre phases et l’approbation des livrables dans son référentiel sur le rôle du sponsor de projet.
Le prestataire ne peut pas arbitrer à la place de son client
L’intégrateur est responsable de la qualité de sa prestation. Il n’est cependant pas neutre dans tous les arbitrages. Son contrat, ses compétences disponibles et son modèle économique influencent naturellement ses recommandations.
Il peut expliquer qu’une fonctionnalité sort du standard. Il ne peut pas décider seul si cette fonctionnalité est indispensable au modèle commercial de l’entreprise. Il peut proposer une interface entre deux applications. Il revient à la PME de déterminer quelles données doivent circuler, quelle application fait foi et qui traite les erreurs. Ces questions sont particulièrement visibles lorsqu’il faut connecter un CRM et un ERP.
L’agilité ne supprime ni le périmètre ni la recette
Travailler par itérations ne signifie pas commencer sans cible, ajouter les demandes au fil de l’eau ou signer le procès-verbal lorsque le budget est épuisé. Le Scrum Guide officiel prévoit des cycles d’un mois au maximum, mais aussi un objectif produit, un responsable de la valeur et une définition explicite de ce qui peut être considéré comme terminé.
Une approche agile fonctionne donc sous conditions : un décideur métier doit être disponible, les priorités doivent être ordonnées et chaque démonstration doit produire une décision. Sans cela, l’agilité devient une succession de réunions qui documentent les retards sans les résoudre.
Le SaaS ne fait pas disparaître les choix techniques
Même lorsque l’infrastructure est gérée par l’éditeur, la PME reste confrontée aux droits d’accès, à la qualité des données, aux interfaces, aux environnements de test, à la réversibilité et à la documentation. Elle doit aussi savoir qui détient les comptes administrateurs et comment récupérer ses données dans un format exploitable.
Le cloud simplifie certaines opérations techniques. Il ne supprime ni la responsabilité du client ni la dépendance créée par un paramétrage mal documenté.
Ce que ça coûte quand on y va sans préparation
Prenons un scénario type, à titre d’illustration : une PME confie le déploiement de son CRM à un intégrateur. Les commerciaux demandent une saisie rapide, la direction financière veut davantage de contrôles et le service client souhaite conserver ses propres catégories. Aucun responsable métier n’est autorisé à trancher.
L’intégrateur paramètre alors les demandes reçues au fil des ateliers. Au moment de la recette, la direction découvre que les indicateurs commerciaux ne sont pas calculés comme prévu. Certaines corrections sont considérées comme des demandes nouvelles, car les règles initiales n’avaient pas été formalisées. La mise en production approche, mais personne ne sait clairement qui peut accepter les écarts restants.
Le coût ne se limite pas à une facture supplémentaire :
| Défaut de pilotage | Conséquence concrète |
|---|---|
| Décisions sans responsable identifié | Attente du prestataire, contournements et arbitrages contradictoires |
| Périmètre métier implicite | Reprises de paramétrage et conflits sur ce qui était inclus |
| Recette préparée à la fin | Anomalies découvertes lorsque les choix sont difficiles à modifier |
| Documentation laissée au fournisseur | Dépendance pour chaque évolution ou extraction de données |
| Interfaces traitées séparément | Doublons, erreurs de synchronisation et responsabilités floues |
| Mise en production dictée par le calendrier | Utilisateurs contraints de travailler avec des réserves non maîtrisées |
Ces problèmes alimentent aussi la dette technique : des solutions provisoires deviennent permanentes, les exceptions s’accumulent et chaque évolution future exige de comprendre des décisions qui n’ont jamais été consignées.
La façon raisonnable d’y aller
1. Donner un mandat explicite au sponsor et au pilote
Le dirigeant nomme un sponsor ayant autorité sur le budget et les priorités, puis un pilote responsable de l’organisation quotidienne. Leur mandat court du cadrage jusqu’à la stabilisation après déploiement. Le livrable attendu est un document de décision indiquant qui tranche le périmètre, les dépenses, les demandes de changement et l’autorisation de mise en production.
2. Protéger une vraie phase de cadrage
Le pilote réunit les responsables métier, les utilisateurs concernés et le prestataire pour décrire le problème, les processus touchés, les données, les interfaces, les contraintes réglementaires et les critères d’acceptation. À titre de repère méthodologique, beta.gouv.fr consacre six à neuf semaines à la validation d’un besoin dans son livre blanc sur la conception des services numériques ; une PME adaptera cette durée à son périmètre, sans supprimer le travail de validation. Le livrable est un dossier de cadrage comprenant le périmètre retenu, les exclusions, les responsabilités, les risques et le plan de recette.
3. Piloter par cycles terminés par une décision
Le pilote découpe le projet en cycles ne dépassant pas un mois, conformément au repère du Scrum Guide. À la fin de chaque cycle, le responsable métier examine une démonstration ou un livrable testable et décide de l’accepter, de demander une correction ou de modifier la priorité. Les livrables sont une liste de travaux actualisée, un relevé de décisions et une vision claire des éléments réellement terminés.
4. Commencer la recette pendant le cadrage
Les utilisateurs référents rédigent des scénarios à partir de leurs opérations réelles : création d’un client, modification d’une commande, import de données, contrôle des droits ou traitement d’une erreur d’interface. Le pilote maintient le cahier de recette pendant tout le projet, et le DPO intervient dès la conception lorsqu’il existe des traitements de données personnelles. La CNIL rappelle que la protection des données et les tests doivent être intégrés durant toute la vie du projet dans son guide Développer en conformité avec le RGPD. Cette démarche complète utilement notre guide sur le RGPD appliqué aux automatisations.
5. Organiser la sortie avant de signer l’entrée
Avant la signature contractuelle, puis à chaque jalon majeur, le pilote vérifie les modalités d’export des données, les accès administrateurs, la propriété des développements, la documentation des interfaces et les conditions de transfert vers un autre prestataire. Le livrable est un dossier de réversibilité mis à jour avec les fichiers exportables, le dictionnaire des données, les procédures d’exploitation et la liste des composants spécifiques.
Lundi matin, ne demandez donc pas seulement où en est le planning. Demandez qui peut décider, quel document définit le périmètre, quels scénarios serviront à la recette et comment l’entreprise reprendra la main sur la solution.
Notre position chez D1 Consulting
Une PME peut piloter un projet IT sans DSI interne. Elle ne peut pas durablement le piloter sans représentant du métier, sans pouvoir de décision et sans méthode de contrôle indépendante du fournisseur.
Notre rôle n’est pas de créer une couche de réunions supplémentaire. Notre offre de Direction de projet IT consiste à cadrer le besoin, organiser les responsabilités, challenger les propositions techniques, suivre les décisions, préparer la recette et sécuriser la mise en production. Le dirigeant conserve les arbitrages stratégiques ; nous lui donnons les informations et les livrables nécessaires pour les prendre avant qu’ils deviennent coûteux.
👉 Réservez un diagnostic gratuit de 30 minutes pour identifier les responsabilités, décisions et livrables qui manquent actuellement à votre projet IT.
