L'usine logicielle dépasse la société de développement

L'intelligence artificielle écrit aujourd'hui une part importante du code. Google a indiqué en avril 2026 que 75 pour cent du nouveau code est généré par l'IA puis validé par des humains. GitHub mesure 46 pour cent sur sa plateforme. Toutes entreprises confondues, la fourchette défendable se situe entre 30 et 50 pour cent.

On s'attendrait à ce que les projets logiciels aboutissent plus vite.

C'est l'inverse qui se produit. Le rapport DORA 2025, fondé sur près de 5'000 professionnels interrogés, aboutit à un résultat inconfortable : avec davantage d'IA, le débit augmente. Mais l'instabilité des livraisons augmente aussi. Les équipes construisent plus vite, mais leurs systèmes ne suivent pas ce rythme.

Stack Overflow fournit la contre-épreuve : 85 pour cent des développeurs utilisent des outils d'IA, mais seuls 29 pour cent font confiance au résultat. C'est la valeur la plus basse jamais mesurée par cette enquête. Et 66 pour cent déclarent passer plus de temps à réparer du code d'IA presque correct qu'ils n'en auraient mis à l'écrire eux-mêmes.

DORA a trouvé un nom pour cela : la taxe de vérification. Le temps gagné à l'écriture se perd au contrôle.

Pourquoi taper plus vite est le mauvais objectif

Dans une société de développement classique, l'écriture ne représente qu'une petite partie d'un projet. Le reste : clarifier les besoins, chiffrer l'offre, monter l'environnement, construire l'authentification, attribuer les droits, connecter les données, tester, sécuriser, livrer, documenter, transmettre.

Si l'IA divise par deux la partie écriture mais que tout le reste ne change pas, le projet n'est pas deux fois plus rapide. Il gagne peut-être un cinquième, tout en devenant plus risqué, car davantage de code doit passer par les mêmes points de contrôle dans le même temps.

Faites le calcul. Si l'écriture représente un quart du projet et que l'IA en divise la moitié, vous économisez un huitième. Quatre mois deviennent trois mois et demi. Ce que le client constate : toujours des mois.

Nathen Harvey, qui dirige DORA, résume ainsi : sans une base faite d'une bonne plateforme interne, de processus clairs et d'équipes alignées, l'IA ne crée que des îlots locaux de productivité, perdus ensuite dans le chaos en aval.

C'est ici que deux voies se séparent.

Ce que coûte la taxe de vérification au quotidien

Un chiffre issu de la recherche rend le problème concret. Une étude contrôlée de l'institut METR a fait travailler des développeurs expérimentés avec et sans outils d'IA. Les participants s'estimaient 20 pour cent plus rapides avec l'IA. Mesurés, ils étaient 19 pour cent plus lents.

La raison n'est pas un code de mauvaise qualité. L'IA écrit du code presque correct. Et presque correct est le type d'erreur le plus coûteux : il ne saute pas aux yeux à la lecture, mais seulement en exploitation.

S'y ajoute la sécurité. Des analyses montrent que le code généré par IA contient nettement plus de vulnérabilités. Travailler sans vérification automatique revient à transférer ce risque au client.

Les deux problèmes sont solubles, mais seulement avec un atelier qui vérifie avant toute livraison. Sans cet atelier, l'IA devient un accélérateur d'erreurs.

Une voie : chaque projet repart de zéro

Une société de développement vend du temps. Chaque mandat est un projet distinct, avec son environnement, son authentification, son système de droits, sa livraison. Ce qui a été construit pour le client précédent sert rarement au suivant. Cela repose dans son dépôt de code et lui appartient.

Ce n'est pas du mauvais travail. C'est un modèle d'affaires dans lequel la répétition ne rapporte pas : qui facture à l'effort a peu de raisons de réduire l'effort.

Pour le client, cela a un effet secondaire désagréable. Chaque solution est isolée, avec sa propre connexion et sa propre maintenance. Après cinq ans, une entreprise moyenne exploite six solutions de ce type qui ne se connaissent pas.

Avec l'IA, cette voie ne s'améliore pas. Elle devient plus rapide. Et plus instable. Car le volume de code passant par les mêmes contrôles manuels augmente, alors que le nombre de relecteurs reste identique.

L'autre voie : l'usine

Une usine ne vend pas des heures. Elle maintient un atelier prêt et y fait passer des produits.

Transposé au logiciel : authentification, droits, séparation des locataires, connexion aux données, journalisation, facturation, livraison. Tout cela est prêt avant qu'un client n'appelle. Ce qui est réellement construit pour un nouveau besoin n'est que la partie véritablement nouvelle.

Il nous a fallu deux ans pour bâtir cet atelier. Non pas pour vendre du logiciel, mais pour disposer de cette manière de construire. Il se trouve près de Berne.

La différence apparaît sur un exemple simple. Un client souhaite que les commandes entrantes soient confirmées automatiquement.

Dans une société de développement : recueillir les besoins, chiffrer, monter le projet, construire la connexion e-mail, concevoir le modèle de données, construire l'interface, clarifier les droits, tester, livrer, former. Deux à quatre mois.

Dans l'usine : la connexion e-mail existe. Les droits existent. L'interface existe. Seule la règle est nouvelle : quelle commande est confirmée quand et comment. Des jours.

Comment un besoin traverse l'usine

Pour que ce ne soit pas qu'une promesse, voici les quatre stations, telles qu'elles fonctionnent chez nous.

Station 1 : le besoin devient un module. Un client décrit ce qui le gêne. Il n'en résulte pas un cahier des charges, mais une liste d'objectifs vérifiables : quelles données entrent ? Que doit-il en sortir ? À quoi reconnaît-on que c'est juste ? Sans cette étape, on ne peut pas mesurer ensuite si cela fonctionne.

Station 2 : on construit sur ce qui existe déjà. Ici, l'IA aide vraiment, mais pas en inventant un système de toutes pièces. Elle assemble des modules existants. La différence est décisive : une IA qui construit sur une surface vide produit du code que personne n'a vérifié. Une IA qui construit sur une plateforme vérifiée produit des liaisons entre des éléments qui fonctionnent déjà.

Station 3 : la vérification est automatique, pas intuitive. Chaque modification passe par les mêmes contrôles : typage, tests, règles de sécurité, séparation des locataires. Pour les systèmes d'IA s'ajoute un quatrième : nous enregistrons chaque étape de décision d'un agent. Quand il se trompe, nous voyons pourquoi, et pas seulement que.

C'est la réponse à la taxe de vérification. Elle ne disparaît pas, mais elle s'exécute automatiquement au lieu d'être manuelle.

Station 4 : la livraison emprunte toujours le même chemin. Aucun client ne reçoit une solution spéciale avec son propre serveur et sa propre maintenance. Tout passe par la même plateforme, la même livraison, la même surveillance. C'est ennuyeux. Et c'est précisément pour cela que c'est fiable.

Les outils déjà disponibles sont présentés dans l'aperçu des outils. La manière dont l'assistant les utilise figure sous assistant IA.

Ce qu'une société de développement ne peut pas offrir

Le modèle d'usine offre un avantage qui n'a rien à voir avec la vitesse.

Quand nous construisons un outil pour un client, il devient ensuite accessible à tous les clients. Semaine après semaine, ce que chacun peut utiliser s'enrichit, sans que personne ne paie davantage.

Une fiduciaire à Berne reçoit une fonction née pour une entreprise artisanale à Thoune. Une entreprise commerciale reçoit une analyse initiée par un prestataire informatique.

Une société de développement classique ne peut pas proposer cela. Ce qu'elle construit pour le client A appartient au client A. Chez nous, les données appartiennent à chaque client. Les outils appartiennent à tous.

L'effet se renforce avec le temps. La première année, une usine n'est guère plus rapide qu'une bonne société de développement, car elle dispose de peu de modules. La troisième année, l'écart est important, car presque chaque besoin rencontre quelque chose qui existe déjà. C'est pourquoi nous avons construit deux ans avant de vendre.

Pour vous : ce que vous commandez aujourd'hui aidera quelqu'un d'autre l'an prochain. Et inversement.

Ce que cela signifie pour les années à venir

L'état de la recherche est assez clair pour risquer un pronostic.

DORA a décrit en 2025 sept capacités fondamentales qui déterminent si l'IA apporte un bénéfice ou du chaos dans une entreprise. Presque toutes concernent non pas l'IA elle-même, mais son environnement : la qualité de la plateforme interne, la clarté des processus, l'alignement des équipes.

Autrement dit : l'avance ne reviendra pas à celui qui a la meilleure IA. Tout le monde dispose des mêmes modèles. L'avance reviendra à celui qui possède un atelier où l'IA peut travailler en sécurité.

Qui recommence aujourd'hui chaque projet de zéro deviendra plus rapide grâce à l'IA. L'écart avec une usine se creusera pourtant, au lieu de se réduire. Car l'usine améliore son atelier à chaque mandat. La société de développement n'améliore que sa vitesse de frappe.

Les limites

Pour éviter toute impression erronée : le modèle d'usine ne rend pas tout rapide.

Si un besoin réclame un module qui n'existe pas encore, cela prend plus de temps. Une connexion à un système métier que personne d'autre n'utilise doit être construite comme partout ailleurs. Chez nous aussi.

La différence, c'est que ce module existe ensuite. Le client suivant avec le même système n'attend plus, et celui d'après non plus.

Nous savons avant de commencer dans quelle catégorie tombe un besoin, et nous vous le disons. Un « trois jours » qui en devient trois semaines n'aide personne.

Deux autres limites en font partie. Qui veut une solution sur son propre serveur à la cave n'est pas au bon endroit chez nous. Et nous ne construisons rien pour des domaines que nous ne maîtrisons pas : technique médicale, commande de machines, sécurité ferroviaire.

Ce que nous savons faire, ce sont les processus métier des petites et moyennes entreprises. Offres, commandes, saisie du temps, documents, analyses, courrier. Tout ce qui traîne aujourd'hui dans Excel et les boîtes de réception. Pour certaines professions, nous l'avons détaillé, par exemple pour la fiduciaire, l'artisanat ou l'architecture.

Les tarifs sont publics sur la page des prix. Aucune demande d'offre n'est nécessaire pour voir un chiffre.

Ce que vous y gagnez

Si vous avez un petit agacement : une offre pour laquelle vous rassemblez des chiffres depuis quatre fichiers, des commandes entrantes que personne ne confirme, un rapport que vous montez à la main chaque vendredi soir : jusqu'ici, aucun projet logiciel ne valait la peine pour cela.

L'effort était sans commune mesure. Un projet de quatre mois pour un problème qui vous coûte une demi-heure par semaine ne se rentabilise jamais. Cela restait donc en l'état. Après cinq ans, vous avez une douzaine de ces agacements, trop petits séparément et trop grands ensemble.

C'est précisément ce que change le modèle d'usine. Non parce que nous tapons plus vite. Mais parce que l'essentiel existe déjà et que votre besoin n'est plus que le dernier module.

Nous avons peut-être déjà résolu votre problème, parce qu'un autre client a posé la même question. Et sinon, nous le résolvons pour vous. Non plus en mois, mais en jours.

Le plus rapide est d'essayer : réserver une démo. Qui préfère composer lui-même utilise le configurateur. Et qui veut savoir qui se cache derrière lit à propos de nous.

Sources

• Google, part de code généré par IA (avril 2026) : 75 pour cent
• GitHub, part sur la plateforme : 46 pour cent
• DORA, State of AI-assisted Software Development 2025 : dora.dev/dora-report-2025
• DORA, The ROI of AI-assisted Software Development (2026) : dora.dev/ai/roi/report
• Stack Overflow Developer Survey : 85 pour cent d'usage, 29 pour cent de confiance, 66 pour cent de reprise
• METR, étude contrôlée sur la vitesse des développeurs avec l'IA