La direction technique, c'est ce qui reste quand le code ne coûte plus rien.

Un dirigeant de PME, 12 mois, 3 décisions et 0 ligne de code

Voici les 3 conversations, dans l'ordre où elles ont eu lieu, avec la situation, la réponse donnée, et ce qui s'est passé ensuite :

Les 3 conversations ont un point commun. Chaque fois, le dirigeant arrivait avec une question d'outil : quel intégrateur, quel logiciel, quelle licence. Chaque fois, la réponse portait sur autre chose : une dépendance à refuser, un pari à prendre, un angle mort à surveiller. La direction technique, c'est cet écart-là, entre la question d'outil et la décision qui compte.

L'histoire du dirigeant immobilier finit bien, et c'est un biais : on raconte plus volontiers celui qui a écouté. La même question a mal tourné 2 fois ailleurs. Une agence a construit trop gros, puis a fermé. Un outil construit avec l'IA n'était plus justifiable par personne. Ces 2 cas sont racontés dans le décryptage sur l'audit technique.

Ce que la direction technique n'est pas : coder, ni fabriquer des outils

On imagine souvent un directeur technique, CTO en anglais, comme le meilleur développeur de l'entreprise. Il l'a souvent été. Mais si son travail se résumait à écrire du code, l'IA l'aurait remplacé cet été, en même temps que les devis à 20 000 € pour un site web. Ce n'est pas ce qui s'est passé.

Un directeur technique fait 3 choses qu'aucun outil ne fait. Il sent dans quelle direction va le marché des outils, et il sait quand un pari devient raisonnable. Il connaît les conséquences à 3 ans d'un choix pris en 3 minutes, parce qu'il a vu ce que devenaient les entreprises qui l'avaient pris. Et il tranche, à la place de quelqu'un qui n'a ni le temps ni le métier pour le faire, en expliquant pourquoi.

Savoir coder sert à juger le code, et c'est utile. Mais prendre les décisions qui comptent ne demande pas d'en écrire une ligne. Dans l'histoire ci-dessus, la valeur produite tient en 3 phrases prononcées au bon moment, et elle a évité un intégrateur inutile, un devis à 5 chiffres et une production sans filet. Et quand il faut construire pour de vrai, c'est la même chose : sur une application de 85 écrans livrée en 3 mois avec l'IA, ce qui a fait la vitesse n'est pas le code, c'est la connaissance du métier chez celui qui répond à l'IA.

Pour un projet IA, le rôle du Forward Deployed Engineer prolonge ce lien entre compréhension du métier et réalisation. L'article liste les questions à poser à un partenaire pour définir un premier périmètre et préparer sa mise en service.

Décision 1 : ne pas acheter une dépendance que vous ne comprenez pas

Dans la première conversation, le dirigeant voulait un intégrateur n8n, et c'était une demande raisonnable : n8n est un bon outil, et des intégrateurs compétents existent. La réponse a été non, et la raison n'avait rien à voir avec l'outil.

Vous achetez une dépendance chaque fois que vous faites poser quelque chose que vous ne comprenez pas, dans un système que vous ne maîtrisez pas. Tant que le prestataire est là, tout va bien. Le jour où il part, change de métier ou double ses prix, vous découvrez que votre entreprise tourne sur 30 automatisations dont personne chez vous ne sait ce qu'elles font. C'est le scénario le plus fréquent derrière une reprise de projet informatique, et il commence toujours par une bonne intention. La même dépendance existe avec un salarié : un décryptage raconte une entreprise dont le logiciel tenait sur un seul développeur, sans que sa direction le sache.

Vous devez maîtriser votre système avant de le faire étendre par quelqu'un d'autre. Maîtriser ne veut pas dire savoir tout construire. Ça veut dire pouvoir répondre à 3 questions :

• Qu'est-ce qui tourne, et à quoi ça sert ?
• Si ça s'arrête demain, comment on continue à travailler ?
• Si le prestataire part, qui sait le faire tourner ?

Le dirigeant a compris ce point en 1 phrase, et il n'a pas pris d'intégrateur. Il y a 12 mois, l'alternative était de tout faire construire. Elle n'existait pas dans son budget. C'est ce qui rend la deuxième conversation intéressante.

Décision 2 : sentir où va le marché des outils, et parier au bon moment

Début 2026, la bonne réponse avait changé. Un an plus tôt, dire à un dirigeant non technique de construire ses outils lui-même aurait été irresponsable. Les assistants d'IA venaient de franchir le seuil où une personne qui connaît son métier, sans savoir coder, peut produire un outil qui tient. Ce seuil ne s'annonce pas dans la presse. Il se voit en travaillant avec ces outils tous les jours.

La consigne a donc été courte : prendre une licence Claude et se former. Et pour que l'associé y croie, une démonstration : leur site web, pour lequel ils avaient reçu des devis de refonte entre 10 000 et 20 000 €, refait en 1 heure, ensemble. Pas un nouveau site : le même que leur WordPress, en code natif, qu'ils font évoluer eux-mêmes depuis, sans agence. Puis la prestation a été mise en pause, faute de budget. Ils avaient ce qu'il leur fallait pour avancer seuls, et ils l'ont fait.

Un dirigeant ne peut pas prendre cette décision seul, et ce n'est pas une question d'intelligence. Il n'a pas le temps de suivre le marché des outils, de tester chaque nouveauté, de distinguer ce qui a franchi un seuil de ce qui fait du bruit. C'est le travail de quelqu'un qui le fait à plein temps. Et le bon pari, pris trop tôt, coûte aussi cher qu'un mauvais pari. L'outil n'est pas prêt, la démonstration rate, et personne ne réessaie avant longtemps.

Un détail compte : la décision consistait à retirer le prestataire de l'équation, y compris le CTO externalisé qui donnait le conseil. Une direction technique qui n'a que des jours de développement à vendre ne vous dira jamais ça. Une direction technique qui vend des décisions, et pas du temps de travail, si.

Décision 3 : savoir ce qui tourne en production avec vos données réelles

En août 2026, le dirigeant a passé l'été à digitaliser son entreprise. Il a raison, et il faut lui dire de continuer. Mais ce qu'il a construit tourne maintenant avec ses vraies données, pour sa vraie équipe : des présentations commerciales envoyées à des clients, et un calcul de rentabilité sur lequel il prend des décisions d'achat. Et il ne voit pas 4 choses. Pas par négligence : parce qu'on ne voit pas ce qu'on ne sait pas chercher. Les 4 angles morts, dans l'ordre où ils font mal :

Ce qui tourne en production, et où

Un clic sur « déployer », le bouton qui met l'outil en service, et ça marche. Chez qui ça tourne, sous quel compte, avec quelle carte bancaire, et qui reçoit le mail quand le compte expire ? Si vous ne pouvez pas répondre en 30 secondes, votre entreprise dépend d'un serveur que personne ne surveille.

Les sauvegardes

Vos automatisations manipulent maintenant vos données réelles : clients, mandats, prix d'achat, loyers. Si la base de données est effacée par une mauvaise manipulation, un vendredi soir, où est la copie d'hier ? La plupart des outils construits en un été n'en ont aucune, parce que personne ne l'a demandée.

Les clés d'accès aux services

Chaque service que vous branchez, l'IA, l'envoi de mails, la signature électronique, vous donne une clé d'API : un mot de passe qui autorise un programme à agir en votre nom. Quand cette clé est collée dans le code, elle finit tôt ou tard dans un fichier partagé. Avec elle, n'importe qui peut envoyer des mails ou consommer de l'IA sur votre compte.

La façon dont tout tient ensemble

Prenez 15 automatisations construites en 15 sessions. Chacune marche. Aucune n'est coordonnée avec les autres. Le jour où vous renommez une colonne dans Coda, laquelle casse ? Si c'est le calcul de rentabilité, l'erreur apparaîtra à la prochaine offre d'achat.

Aucun de ces 4 points ne se voit à l'écran, et l'IA n'en parle pas d'elle-même. Elle construit ce qu'on lui demande, et personne ne lui demande une sauvegarde sans savoir qu'il en faut une. Les 3 risques d'un outil interne construit avec l'IA sont détaillés dans un autre décryptage. Ici, le sujet est ce qui vient après : l'outil existe, il tourne, et quelqu'un doit être responsable des données qu'il manipule.

Vous pouvez couvrir les 4 en quelques jours. À condition que quelqu'un vous ait dit qu'ils existent, et dans quel ordre les traiter. C'est toute la différence entre continuer sereinement et découvrir le problème par un client.

S'y ajoute une tendance de fond, qui ne vise pas votre outil en particulier. Les attaques sur les applications augmentent, y compris sur les plus classiques. La raison : des modèles d'IA dont les poids sont publics tournent sans garde-fou, et n'importe qui peut se faire expliquer comment attaquer un site. Un outil construit en un été n'est pas plus visé qu'un autre. Il a simplement rarement été construit pour résister.

Ce qu'un dirigeant qui sait automatiser ne peut toujours pas trancher seul

Savoir construire ne suffit pas. Restent des décisions qu'un dirigeant ne peut pas prendre seul, non par manque de compétence, mais parce qu'elles demandent d'avoir vu leurs conséquences ailleurs, avant. Les 3 décisions qui reviennent dans toutes les PME qui s'outillent elles-mêmes :

Ce qui va durer dans le marché des outils

Coda, n8n, Claude, et les 20 outils qui sortiront l'an prochain. Lequel sera encore là dans 3 ans, lequel vous enferme, lequel vient d'être racheté par un éditeur qui va doubler le prix ? Ce marché se suit à plein temps, et un mauvais pari se paie en réécriture complète.

Quand et quoi confier à un professionnel

Tout ne se construit pas en un été. Une facturation, un accès client, une intégration avec votre banque : le coût d'une erreur y dépasse le coût de le faire faire par un professionnel. Savoir où passe cette ligne, chez vous, avec vos volumes, c'est une décision de direction technique, pas une compétence d'outil.

Ce qui va en production avec des données réelles

Un outil pour vous seul peut vivre avec des approximations. Le jour où il contient les données de vos clients et où votre équipe s'en sert, il devient un actif à protéger, avec des obligations légales sur les données personnelles. Ce passage se fait sans bruit, et il ne se voit pas de l'intérieur.

Les 3 conversations de l'histoire se retrouvent dans ces 3 lignes. Elles n'ont rien de propre à l'immobilier. Le dirigeant du transport, celui de la santé et celui de la distribution posent les mêmes questions, avec d'autres outils. Et la réponse dépend chaque fois de l'entreprise, de ses volumes, de ses clients, de ce qu'elle risque : c'est pour ça qu'un article ne peut pas la donner, et qu'une direction technique le peut.

Les 2 façons de couvrir vos angles morts sans arrêter de construire

Vous avez 2 options, et elles se combinent. La première : vous former aux notions de base, sans devenir développeur. Savoir ce qu'est un hébergement, une sauvegarde, une clé d'accès, un espace de test séparé de vos vraies données. Une semaine d'attention suffit pour ne plus faire les grosses erreurs, et l'IA est un bon professeur, si vous savez quoi lui demander.

La seconde : faire valider vos arbitrages par quelqu'un dont c'est le métier, à temps partiel. Pas pour construire à votre place, vous le faites mieux et plus vite. Pour trancher les 3 décisions du chapitre précédent, relire ce qui existe, et vous dire quand vous approchez d'un mur. Quelques heures par mois, avec un volume qui baisse dès que les angles morts sont couverts.

Comptez 1 à 2 jours pour la relecture elle-même. Elle passe les 4 angles morts un par un sur ce qui tourne réellement chez vous, et rend 2 pages : ce qui casserait en premier, et dans quel ordre le traiter. C'est la version réduite d'un audit technique, réservée à ce que vous avez construit vous-même.

Choisissez selon ce que vous risquez. Un outil pour vous seul, avec des données de test : formez-vous, et continuez. Un outil sur lequel votre équipe travaille, avec les données de vos clients : faites relire, maintenant, avant que le coût d'une erreur ne dépasse le coût de la relecture. Si vous voulez faire grandir l'entreprise sur ces outils, les 2 à la fois.

Comment décider : la séquence, dans l'ordre

Voici les 7 étapes à suivre, dans cet ordre, sans en sauter une :

1. 1

   Continuer à construire vous-même. Vous êtes la personne qui connaît le mieux votre entreprise, et c'est ce qui compte désormais. Personne ne vous le reprendra.

2. 2

   Écrire sur 1 page ce qui tourne : chaque outil, où il est hébergé, c'est-à-dire sur quel ordinateur distant il tourne, sous quel compte, et ce qu'il touche comme données. Si vous ne pouvez pas remplir la page, c'est votre premier chantier.

3. 3

   Mettre une sauvegarde automatique sur tout ce qui contient des données de clients, et vérifier 1 fois que vous savez la restaurer. Une sauvegarde jamais testée n'existe pas : vous découvririez qu'elle est vide le jour où vous en avez besoin.

4. 4

   Sortir les clés d'accès du code, les ranger dans un coffre-fort à mots de passe, et savoir les désactiver. Prévoir 1 après-midi.

5. 5

   Choisir votre façon de couvrir les angles morts : vous former aux notions de base, ou faire valider vos arbitrages par quelqu'un dont c'est le métier. Les 2 se combinent.

6. 6

   Faire relire ce qui existe avant d'accueillir votre équipe ou vos clients dessus. Une relecture courte, qui liste ce qui casserait en premier.

7. 7

   Poser vos 3 décisions de l'année, celles que vous ne pouvez pas trancher seul : les outils sur lesquels parier, ce que vous confiez à un professionnel, ce qui doit être protégé. Puis décider qui les tranche avec vous.

Suivez ces 7 étapes sans arrêter de construire. Les 4 premières se font seul, en quelques jours. Les 3 dernières sont celles où une direction technique change quelque chose, et le format à temps partiel est décrit dans le guide du CTO externalisé.

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 →

Questions fréquentes

Sources

Références consultées pour cette version du 26 août 2026. Le cas raconté est réel et anonymisé ; les montants des devis sont ceux reçus par l'entreprise, pas des prix pratiqués sur ce site.

• Anthropic, « Detecting and countering misuse of AI », août 2025 : usage d'assistants d'IA pour attaquer des applications ↗
• Wikipédia, « Clé d'API », ce qu'autorise une clé d'accès ↗