Quand une PME a besoin d'un Fractional Digital Architect
Entre 'le dirigeant s'en occupe' et 'on recrute un DSI', il existe un modèle adapté à de nombreuses PME. Quand ça fonctionne, quand ça ne fonctionne pas.

La plupart des entreprises de taille moyenne n’ont pas un problème informatique. Elles ont un problème d’architecture.
Les outils fonctionnent. Les serveurs tournent. Les e-mails arrivent. Mais personne n’a la vision d’ensemble. Personne ne décide quelle solution logicielle reste et laquelle part. Personne ne s’assure que les systèmes évoluent avec la croissance de l’entreprise. Classiquement, ce vide est comblé par un DSI ou un responsable informatique. Pour une entreprise de 30 collaborateurs, c’est inabordable. Alors le vide reste ouvert.
Un Fractional Digital Architect le comble. Non pas comme un prestataire informatique externe qui traite des tickets. Mais comme une fonction stratégique achetée à temps partiel.
Ce que fait un Fractional Digital Architect
Trois choses :
Établir une vue d’ensemble. Quels systèmes sont en place, comment s’articulent-ils, où se trouvent les sources de vérité. Une cartographie proprement documentée est le fondement de toute décision. Elle n’existe pas dans la plupart des PME.
Préparer les décisions. Quelle solution doit être remplacée, laquelle doit rester. Où l’intégration est pertinente, où la migration l’est. Si un nouvel outil est vraiment nécessaire ou si un outil existant est simplement mal exploité. La direction prend la décision, mais elle reçoit au préalable une recommandation étayée plutôt qu’un argumentaire commercial soigné.
Coordonner la mise en œuvre. Quand une migration est en cours, quelqu’un est responsable de s’assurer qu’elle ne s’enlise pas. Les prestataires sont pilotés, les délais sont tenus, les écueils sont anticipés. Pas question de tout faire soi-même, mais de s’assurer que les bonnes choses sont faites.
Quand le modèle convient
Le modèle convient quand les trois conditions suivantes sont réunies :
- L’entreprise est suffisamment grande pour que l’informatique soit suffisamment complexe pour justifier une stratégie (à partir d’environ 10 collaborateurs).
- L’entreprise est suffisamment petite pour qu’une direction informatique à plein temps ne soit pas économiquement viable (jusqu’à environ 80 collaborateurs).
- Il existe au niveau de la direction générale quelqu’un prêt à traiter l’informatique comme un sujet stratégique, et non comme une contrainte.
Le troisième point est le filtre le plus difficile. Si la direction s’attend à ce que “l’informatique se gère seule”, le modèle ne fonctionne pas. Les décisions stratégiques ne se délèguent pas — elles se préparent.
Quand le modèle ne convient pas
Le modèle ne convient pas quand :
- Le vrai problème est concret (imprimante en panne, connexion lente, boîte mail piratée). Cela requiert un prestataire informatique, pas un architecte.
- L’entreprise dispose déjà d’un responsable informatique compétent en interne. Il n’y a alors personne à compléter.
- L’attente est que quelqu’un soit disponible 24h/24 et 7j/7 pour réparer des écrans. C’est du travail de help-desk, pas d’architecture.
- L’objectif est de constituer une équipe de développement logiciel en interne. C’est une autre fonction (CTO, Engineering Lead).
Honnêtement : dans deux entretiens initiaux sur trois, je finis par recommander autre chose qu’une collaboration. Un bon prestataire local, un projet logiciel spécifique avec un spécialiste, le recrutement d’une personne en interne. Quand le modèle convient, il convient vraiment. Quand il ne convient pas, aucun effort n’y changera quoi que ce soit.
Comment débute une collaboration
L’entretien initial permet de déterminer si le modèle convient. Si c’est le cas, un état des lieux structuré suit : deux à trois jours de travail, qui aboutissent à une cartographie documentée des outils et à une liste de recommandations priorisées. Cela débouche ensuite soit sur un projet concret avec une fin clairement définie, soit sur un accompagnement régulier sous forme de mandat mensuel, soit sur le constat que des prérequis internes doivent d’abord être traités.
Ce qui n’arrive pas : un contrat annuel sans période d’essai. Si travailler avec la visibilité d’un architecte ne convient pas à l’organisation, cela doit apparaître rapidement — pas après des mois.