Quand une entreprise a besoin d'une architecture numérique externe

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.

Avec l’IA, ce vide s’est agrandi, pas réduit. Il existe désormais des outils avec un vrai levier, même dans une petite entreprise. Mais quelqu’un doit décider quel cas d’usage tiendra la route, où les données ont le droit de circuler et comment le nouveau s’intègre aux systèmes existants. C’est précisément un travail d’architecture.

Un Fractional Digital Architect le comble. Non pas comme un prestataire informatique externe qui traite des tickets. Mais comme une fonction stratégique externe.

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é. Si un projet IA a un vrai levier chez vous ou n’est que l’effet de mode du moment. La direction prend la décision, mais elle reçoit au préalable une recommandation étayée plutôt qu’un argumentaire commercial soigné.

Piloter la mise en œuvre, construire les parties critiques. 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. Et là où cela compte, je construis moi-même : chez moi, les cas d’usage IA et les automatisations ne finissent pas en documents de concept, mais en systèmes opérationnels. Des exemples sont visibles dans le Lab.

Quand le modèle convient

Le modèle convient quand les trois conditions suivantes sont réunies :

1. L’entreprise est suffisamment grande pour que l’informatique soit suffisamment complexe pour justifier une stratégie (à partir d’environ 10 collaborateurs).
2. L’entreprise est suffisamment petite pour qu’une direction informatique dédiée ne soit pas économiquement viable (selon la structure, jusqu’à environ 300 collaborateurs – le critère décisif est l’absence d’une organisation informatique interne de type grand groupe).
3. 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 compact suit, qui aboutit à 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, soit sur le constat que des prérequis internes doivent d’abord être traités.

Ce qui n’arrive pas : un grand mandat 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 une longue inertie.