Quiconque a fait des travaux chez soi connaît la règle sans l'avoir lue nulle part : peindre un mur, ça se fait le week-end ; changer une prise, avec précaution, aussi ; toucher au tableau électrique ou abattre une cloison, c'est une autre histoire — il faut quelqu'un qui sache, et parfois un plan et un permis. Le critère n'est pas la taille de la maison. C'est ce qui se passe si ça tourne mal, et ce que coûte d'apprendre à bien le faire.
Avec l'IA, c'est la même chose, et la différence en 2026, c'est que les outils pour « faire soi-même » sont devenus très bons. Un dirigeant sans formation technique peut aujourd'hui, avec Codex, Claude Code ou Copilot, construire une automatisation, un prototype ou une analyse qui, il y a deux ans, exigeait une équipe. C'est vrai, et c'est une bonne chose. Il est tout aussi vrai qu'il n'a jamais été aussi facile de construire quelque chose qui marche en démo et que personne ne saura maintenir trois mois plus tard.
Cet article est une tentative honnête de répondre à la question qu'on nous pose chaque semaine — « ça, on le fait nous-mêmes ou on a besoin d'aide ? » — y compris dans les cas où la bonne réponse est « faites-le vous-mêmes », et ils sont nombreux.
Ce que ces outils ont changé
Il vaut la peine de distinguer trois choses qui arrivent souvent mélangées.
Les assistants dans l'éditeur. GitHub Copilot est né comme suggestion de code dans l'IDE et répond aujourd'hui aussi à des questions sur le code et exécute des tâches — mais sa place naturelle est aux côtés de quelqu'un qui programme, pour accélérer ce que cette personne sait déjà faire. S'il n'y a personne pour programmer, il n'y a personne à qui suggérer.
Les agents de code. Le Codex d'OpenAI et le Claude Code d'Anthropic sont une autre catégorie : ils reçoivent une tâche (« relie ce formulaire à la base de données et envoie un e-mail quand une demande arrive »), lisent le projet, écrivent le code dans plusieurs fichiers, lancent les tests et rendent le résultat. Ils fonctionnent dans le terminal, dans l'éditeur, dans le cloud. C'est ce qui permet à quelqu'un sans équipe technique de construire des choses réelles.
Les modèles derrière. Les mêmes LLM qui alimentent ces outils sont disponibles par API pour construire des produits et des automatisations. C'est un autre niveau de travail, et le seul où les outils pour « faire soi-même » ne suffisent pas à eux seuls.
Ce que les trois ont en commun : ils ont fait chuter le coût de commencer. Ils n'ont pas fait baisser le coût de maintenir, d'intégrer, ni de répondre quand quelque chose échoue avec des données clients à l'intérieur.
Quand faire soi-même est la bonne réponse
Il y a plus de cas qu'un cabinet de conseil n'aimerait l'admettre. Voici ceux que nous voyons bien fonctionner sans aide extérieure :
Usage personnel et d'équipe. Résumer des réunions, préparer la première version d'un document, analyser un tableur, rédiger un e-mail délicat. Pas d'intégration, pas de données de tiers qui sortent de l'entreprise (à condition que l'outil soit le bon — voir plus bas), et le seul risque est de perdre une heure. Faites-le.
Des prototypes pour décider. « Un assistant sur notre base de connaissances servirait-il à quelque chose ? » La meilleure façon de répondre est d'en construire un en deux jours avec un agent de code et de le montrer à trois personnes. Un tel prototype vaut plus qu'une étude de faisabilité de quarante pages — et si l'on décide ensuite d'avancer sérieusement, le prototype est le meilleur brief qu'un consultant puisse recevoir.
Des processus internes à faible risque. Un script qui renomme des fichiers, une automatisation qui compile un rapport hebdomadaire à partir de trois sources, un formulaire interne. Si ça échoue, quelqu'un s'en aperçoit et le fait à la main. Inutile d'impliquer quelqu'un de l'extérieur.
Des équipes techniques qui ont juste besoin d'accélérer. S'il y a déjà des développeurs, Copilot ou Claude Code sont des outils de productivité, pas un projet. C'est à l'équipe de les adopter — avec un avertissement, plus bas, sur ce que disent les études.
Quand l'objectif est d'apprendre. Certaines entreprises veulent que l'équipe comprenne ce que l'IA fait et ne fait pas avant de décider où investir. Construire de petites choses, avec les mains, est la meilleure formation qui soit. Aucun cours ne la remplace.
Ce que ces cas ont en commun : le coût de l'erreur est faible, les données sont les vôtres et rien n'en dépend pour fonctionner demain matin.
Quand faire soi-même coûte cher
Les signes que le chantier n'est plus un chantier de week-end :
Des données clients. Dès que la solution touche des noms, des e-mails, des contrats, des factures ou un historique d'achats, il y a le RGPD, il y a des sous-traitants, il y a la question « où va tout ça ? » La plupart des problèmes que nous voyons dans les solutions faites maison ne sont pas dans le code — c'est le modèle qui reçoit des données qu'il ne devrait pas recevoir, sans que personne ne l'ait décidé.
L'intégration avec des systèmes critiques. ERP, CRM, facturation, banque. Un agent de code écrit l'intégration en une demi-heure ; ce qu'il ne sait pas, c'est que la table clients a trois champs hérités que personne n'a documentés, que l'ERP rejette les mises à jour hors horaires et que la synchronisation lancée deux fois duplique les factures. Quiconque a cassé une intégration de ce genre sait ce que ça coûte.
Des processus qui traversent les équipes. Si la solution change en même temps la façon de travailler du commercial, des opérations et de la finance, le problème n'est plus technique. C'est de la conception de processus, de la conduite du changement, la décision de qui fait quoi. Aucun outil de code ne résout cela.
« Ça marche sur mon portable. » La solution vit sur la machine d'une personne, avec une clé d'API personnelle, sans gestion de versions, sans personne pour la comprendre si cette personne s'en va. C'est l'équivalent d'une installation électrique improvisée : ça marche jusqu'au jour où ça ne marche plus.
Pas d'indicateur de résultat. On l'a construite parce que c'était possible. Personne n'a défini ce qui devait changer — temps, coût, erreurs, chiffre d'affaires — et personne ne mesure. Au bout de six mois, personne ne sait si ça en valait la peine.
Personne pour maintenir. Les modèles changent, les API changent, les prix changent. Une solution avec de l'IA n'est pas un tableur : il lui faut quelqu'un pour la suivre. Si cette personne n'existe pas, la solution a une date de péremption.
Et il y a l'avertissement promis à propos des équipes techniques. Une étude du METR de 2025, avec des développeurs expérimentés sur de vrais projets open source, a mesuré ce que personne n'attendait : avec des outils d'IA, ils ont mis 19 % de temps en plus pour clore les tâches — tout en restant convaincus d'avoir été 20 % plus rapides. Le rapport DORA 2024 pointe dans la même direction : l'IA a augmenté la productivité individuelle et la satisfaction, mais dégradé la stabilité et le débit des livraisons. La leçon n'est pas « n'utilisez pas » ; c'est que la sensation de vitesse n'est pas la vitesse, et que sans processus autour, l'outil accélère la personne et freine le système.
Le juste milieu qui fonctionne
En pratique, le choix est rarement binaire. Les deux modèles hybrides qui fonctionnent le plus souvent :
Diagnostic externe, exécution interne. Quelqu'un de l'extérieur cartographie le processus, identifie où l'IA vaut la peine et où elle ne la vaut pas, définit les indicateurs et conçoit la solution — et l'équipe construit avec les outils d'agent. L'entreprise garde le savoir ; le consultant intervient là où l'expérience compte (savoir ce qui tourne mal d'habitude) et se retire avant de devenir une dépendance.
Pilote interne, passage à l'échelle avec de l'aide. L'équipe construit le prototype, prouve qu'il y a de la valeur, et c'est seulement ensuite qu'intervient celui qui va le rendre robuste : intégration, sécurité, données, supervision, formation. C'est la version « j'ai peint le salon moi-même, j'ai appelé l'électricien pour le tableau ».
Dans les deux cas, la question à poser au consultant est la même : « quand partez-vous ? » Si la réponse est vague, c'est le signe que le modèle économique est de rester.
Les outils, sans les prix
Les prix changent d'un mois à l'autre et seraient périmés avant même la lecture de cet article ; pour estimer les coûts d'usage, nous tenons à jour un guide des coûts de l'IA. Ce qui change moins vite, c'est le positionnement de chacun :
- GitHub Copilot — le plus intégré au flux de ceux qui programment déjà (éditeur, GitHub, revue de code). Le choix naturel pour les équipes techniques qui veulent accélérer sans changer d'outils.
- OpenAI Codex — agent de code avec une CLI, une extension pour l'éditeur et un environnement cloud ; il exécute des tâches entières, y compris en parallèle, et s'intègre à l'écosystème OpenAI.
- Claude Code — agent de code qui lit tout le projet, modifie les fichiers, lance des commandes et se connecte à des outils externes (documents, tickets, bases de données) via MCP ; disponible dans le terminal, l'éditeur, une application de bureau et le navigateur.
Pour quelqu'un de non technique qui veut construire des prototypes ou des automatisations, les deux agents (Codex et Claude Code) sont le point de départ ; Copilot suppose un développeur dans le fauteuil. Pour ceux qui ont déjà une équipe, n'importe lequel convient — ce qui décide, c'est ce que l'équipe utilise déjà.
Une remarque valable pour les trois : lisez ce que chacun fait des données qu'on lui confie (le code, les documents, ce qui est tapé dans les prompts) et choisissez les offres entreprise dès qu'il y a des données clients. C'est la différence entre peindre le mur et toucher au tableau électrique.
Matrice de décision
Trois questions, et la réponse tombe presque d'elle-même.
| Risque faible (données internes, réversible) | Risque élevé (données clients, systèmes critiques, argent) | |
|---|---|---|
| Capacité interne (quelqu'un pour construire et maintenir) | Faire soi-même. Outils d'agent, indicateur défini, revue au bout d'un mois. | Diagnostic externe, exécution interne. Quelqu'un de l'extérieur conçoit et fixe les limites ; l'équipe construit. |
| Pas de capacité interne | Faire soi-même pour apprendre, avec un périmètre réduit. Prototypes, automatisations personnelles, sans intégration. | Conseil avec date de sortie. Diagnostic, mise en œuvre jusqu'à ce que ça fonctionne, formation de l'équipe pour maintenir. |
La troisième question est l'urgence : si le résultat est nécessaire en quelques semaines et qu'il n'y a pas de capacité interne, le coût d'apprendre en chemin dépasse celui de quelqu'un qui l'a déjà fait.
Que demander à un cabinet de conseil avant de signer
Si la matrice a désigné l'aide extérieure, ces questions séparent ceux qui accélèrent de ceux qui vendent des heures :
- « Qu'allez-vous décider de ne pas faire ? » Un bon consultant retire des choses du périmètre. Un mauvais accepte tout.
- « Quel est l'indicateur, et quand le mesure-t-on ? » Si la réponse est « la productivité » sans chiffre, il n'y a pas d'indicateur.
- « Qu'est-ce qui reste chez nous à la fin ? » Le code, la documentation, les accès, et une équipe qui sait maintenir. S'il reste des dépendances, il reste des factures.
- « Quand partez-vous ? » Une date, ou un critère. « Quand ça fonctionne » est une réponse acceptable si elle vient avec la définition de « fonctionne ».
- « Montrez-moi un cas où vous avez dit à un client de ne pas utiliser l'IA. » Celui qui ne l'a jamais dit manque d'expérience ou d'honnêteté.
- « Qui fait le travail ? » Les personnes qui présentent la proposition sont-elles celles qui vont exécuter ? Sinon, qui, et avec quelle expérience de processus comme le nôtre ?
- « Que se passe-t-il quand le modèle change ? » Les fournisseurs retirent des modèles, changent les prix, changent les comportements. Qui suit cela ensuite ?
Notre réponse à ces questions se trouve dans notre façon de travailler : nous décidons ce qui change, nous restons jusqu'à ce que ça fonctionne, avec des livraisons hebdomadaires et une date de sortie. Si la bonne réponse pour votre cas est « faites-le vous-mêmes », c'est ce que nous disons — et le diagnostic gratuit sert précisément à le découvrir avant tout contrat.
Questions fréquentes
Puis-je construire une automatisation avec de l'IA sans savoir programmer ? Avec un agent de code comme Codex ou Claude Code, oui, pour des cas à périmètre réduit et à faible risque : automatisations internes, prototypes, analyses. Ce qu'on n'obtient pas sans expérience, c'est l'intégration avec des systèmes critiques, la garantie de protection des données et la maintenance de la solution quand les modèles changent.
Copilot, Codex ou Claude Code — lequel choisir ? S'il y a des développeurs, ce que l'équipe utilise déjà ; Copilot est le plus intégré au flux de ceux qui programment. S'il n'y en a pas, les agents (Codex, Claude Code) sont le point de départ, parce qu'ils exécutent des tâches entières à partir d'une description.
Quand un cabinet de conseil se justifie-t-il ? Quand les données sont celles de clients, que la solution touche des systèmes critiques, que le processus traverse les équipes, ou que le résultat est nécessaire en quelques semaines sans capacité interne. Et il doit intervenir avec une date de sortie.
Les études disent-elles que l'IA ralentit les développeurs ? Une étude contrôlée du METR (2025) a mesuré des développeurs expérimentés 19 % plus lents avec des outils d'IA, alors qu'ils se sentaient plus rapides ; DORA 2024 a vu la productivité individuelle monter et la stabilité des livraisons baisser. La conclusion est qu'un outil sans processus accélère la personne et freine le système — pas qu'il ne faut pas l'utiliser.
Le prototype que nous avons fait en interne sert-il à quelque chose si nous faisons ensuite appel à de l'aide ? À beaucoup : il prouve qu'il y a de la valeur, montre le processus réel et constitue le meilleur brief possible. Ce qui, en général, ne sert pas, c'est le code du prototype, conçu pour démontrer et non pour durer.
Sources
Écrit sur l'IA appliquée, l'opération, le GEO/SEO et comment transformer les entreprises en machines qui continuent à tourner même quand personne ne regarde.