Stock de dalles maison avec l’IA : là où le succès rapide bascule
Avec l’IA, un logiciel de stock maison est vite construit. Il devient coûteux au quotidien d’un atelier de pierre, quand chaque réparation entraîne de nouvelles erreurs. Comment reconnaître ce point de bascule et quelles questions se poser avant de décider.
- L’attrait : quelques heures au lieu de plusieurs mois
- La courbe : enthousiasme, quotidien, erreurs
- Le piège : plus on a investi, plus il est difficile d’en sortir
- Ce qui arrive : le passeport numérique des produits
- Ce qui plaide pour le développement maison
- Ce que contient une solution qui a mûri
- La meilleure voie : se connecter plutôt que reconstruire
Avec l’IA, une liste de stock ou une petite galerie de dalles se construit aujourd’hui en un après-midi. Cela fonctionne tant qu’une seule personne l’utilise et que rien d’inhabituel ne se produit. Or, au quotidien d’un atelier de pierre, l’inhabituel arrive sans cesse, par exemple quand deux vendeurs proposent la même dalle. C’est là que les erreurs du programme commencent, et chaque réparation rapide peut en créer de nouvelles.
L’attrait : quelques heures au lieu de plusieurs mois
« Vibe Coding » : c’est ainsi que le chercheur en IA Andrej Karpathy a baptisé en février 2025 ce que beaucoup essaient aujourd’hui. On décrit en langage courant ce que le programme doit faire, l’IA écrit le code, et on le reprend sans le lire soi-même. Au bout d’un après-midi, on obtient souvent un tableau avec matériau, format et épaisseur, photo et filtres.
Pour certaines tâches, c’est exactement ce qu’il faut : une vue d’ensemble rapide pour un salon professionnel ou l’exploitation des contacts recueillis sur un salon. Dès que ces données doivent alimenter un projet en cours, cela devient délicat. Le Fraunhofer IESE cite le prototypage rapide comme un point fort, tout en mettant en garde contre le risque de voir le prototype finir dans le système définitif. « Les risques augmentent avec la complexité et la criticité de l’application. » Un stock de dalles qui sert à vendre est les deux à la fois.
La courbe : enthousiasme, quotidien, erreurs
Puis vient le quotidien, et avec lui des cas auxquels personne n’a pensé au moment de la description :
- Une dalle n’est pas un article. Chaque tranche brute est une pièce unique, avec son propre contour et son propre veinage. Une liste qui indique « matériau, 20 m² » ne sait pas quelle dalle va avec laquelle.
- Séquences de bloc. Un bookmatch exige les dalles consécutives et symétriques d’un même bloc, un blending harmonieux des dalles issues du même bloc. Si l’une d’elles part seule, c’est précisément sa voisine qui manque sur la surface.
- Les chutes reviennent. Après la découpe, il reste une chute au nouveau contour. Nouvelle entrée, modification ou déduction ? La réponse détermine le stock, le prix et la photo.
- Des dalles cassent, des emplacements changent. Une dalle casse lors d’un déplacement, une autre se trouve sur un autre chevalet. Dans le système, toutes deux restent inchangées, et une offre continue de courir.
- Deux vendeurs, une dalle. Dès que plus d’une personne vend, il faut des réservations visibles par tous.
- Tout s’imbrique. Un processus qui fonctionne pour des carreaux de sol au mètre carré ne fonctionne pas automatiquement pour des plinthes au mètre linéaire. Ce qui est juste dans l’offre doit aussi l’être dans la commande, le bon de livraison et l’étiquette.

Un cas concret montre à quel point le déclencheur peut être minime. Un programme de planification écrit en interne fonctionnait parfaitement sur plusieurs projets individuels. Lorsque les données de plusieurs projets ont été réunies, il s’est bloqué. Il numérotait les pièces avec des lettres et parcourait l’alphabet ; personne n’avait défini ce qui vient après le Z. L’erreur a vite été corrigée, mais elle a eu des conséquences sur l’exécution et la représentation des plans, qu’il a fallu reprendre partout. C’est le déroulement typique : le résultat arrive vite. Les cas où il bloque n’arrivent que lorsque l’entreprise et ses collaborateurs utilisent réellement le programme.
Chacun de ces cas peut être décrit à l’IA, et elle livre une solution. C’est là que se trouve le piège : la réparation corrige, en une ou plusieurs tentatives, le problème visible et modifie souvent en arrière-plan des choses qui fonctionnaient auparavant. Dans le vibe coding, selon le Fraunhofer IESE, « les messages d’erreur sont simplement transmis directement à l’IA comme nouveau prompt ». L’institut cite comme risque la baisse de la compréhension du système : le code généré est difficile à suivre.
Une raison tient au mode de travail de l’IA. Une personne qui construit un programme pendant des mois se souvient pourquoi une chose a été résolue de telle façon. L’IA travaille avec ce qui figure dans la conversation en cours. Au fil des sessions, on change de chat sans tout transmettre, ou la conversation devient si longue que les parties antérieures ne sont plus prises en compte de manière fiable. L’équipe de recherche de Chroma a testé 18 modèles de langage : dans tous les essais, les performances baissaient à mesure que l’entrée s’allongeait. C’est précisément là que naissent les réparations qui cassent quelque chose ailleurs.
À chaque réparation, le code grossit, et faute de comprendre la logique, il devient plus compliqué que nécessaire : sections en double, détours, boucles dans des boucles. Un indice vient du développement professionnel : la société d’analyse de code GitClear a étudié 211 millions de lignes de code modifiées entre 2020 et 2024. La part des lignes copiées est passée de 8,3 à 12,3 %, celle des lignes remaniées est tombée de 25 % (2021) à moins de 10 % (2024). Ce remaniement prend du temps, demande des compétences et dépasse en général ce que veut fournir quelqu’un qui « construit ça vite fait soi-même ».
Reste la sécurité. Veracode a examiné le code de plus de 100 modèles d’IA : dans 45 % des tests, il contenait des failles de sécurité à risque. Le générateur d’applications par IA Lovable a montré en 2025 à quoi cela ressemble : sur 1 645 applications examinées construites avec cet outil, 170 avaient des droits d’accès si lacunaires que des données comme des noms, des numéros de téléphone et des données de paiement étaient exposées. Pour un stock de dalles qui affiche en ligne des prix et des données clients, c’est lourd de conséquences.
Le piège : plus on a investi, plus il est difficile d’en sortir
Un système construit en interne ne devient généralement coûteux qu’après son lancement, pendant ces semaines où l’on corrige encore une erreur le soir et où une nouvelle apparaît le matin. Ces heures manquent à la vente et au relevé de mesures. Plus on y a investi de temps, plus il est difficile de dire : « On arrête et on prend une solution toute faite. » En psychologie, on parle de l’effet des coûts irrécupérables : le temps déjà investi retient, même quand l’étape suivante ne vaut plus la peine.
Et l’on remarque à peine combien de temps y passe. Dans une étude du groupe de recherche METR, 16 développeurs expérimentés ont traité des tâches réelles dans leurs propres grands projets open source, développés au fil des années, tantôt avec, tantôt sans les outils d’IA du début de 2025. Mesuré, il leur fallait 19 % de temps en plus avec l’IA, et pourtant ils pensaient ensuite avoir été 20 % plus rapides. Pour les outils plus récents, les auteurs estiment désormais ce retard plus faible, tout en qualifiant eux-mêmes leurs données sur ce point de fragiles. Ce qui reste remarquable, c’est l’écart entre ressenti et mesure. Si même des professionnels évaluent aussi mal leur propre rythme, quelle fiabilité accorder à l’auto-évaluation de quelqu’un qui programme pour la première fois, en parallèle de son travail ?
Les signes qui montrent qu’on est pris au piège :
- Chaque semaine s’ajoute une réparation, et la liste des erreurs ouvertes ne raccourcit pas.
- Les questions sur le programme aboutissent toujours chez le même collègue, et quand il est en congé, l’entreprise attend.
- Après une modification, personne ne vérifie le système dans tous les sens, c’est-à-dire offre, bon de livraison et étiquette. Seul le quotidien révèle si quelque chose a été cassé.
- Personne n’a encore additionné les heures qui ont été consacrées au programme maison et qui continuent de l’être.
Si plus d’un point s’applique, un calcul honnête avec trois chiffres s’impose : les heures que coûte chaque mois le développement maison (deux semaines de relevé suffisent), le prix mensuel d’une solution professionnelle et le temps que l’équipe gagne avec elle à la vente et au stock, idéalement mesuré lors d’un test sur son propre stock.
Ce qui arrive : le passeport numérique des produits
Le nouveau règlement européen Produits de construction (UE) 2024/3110 s’applique depuis le 8 janvier 2026 et introduit le passeport numérique des produits pour les produits de construction. Selon le Deutsches Institut für Bautechnik (DIBt), il deviendra obligatoire dès que la Commission européenne aura adopté l’acte juridique correspondant, après une période de transition de 18 mois. Cet acte juridique déterminera quels produits et quelles données il couvre. On peut déjà prévoir que les données produits devront être disponibles sous forme numérique et dans un format défini. Une solution construite en interne devra alors subir une refonte que chaque entreprise assume seule. Un fournisseur qui sert de nombreuses entreprises doit la résoudre une seule fois pour tous.
Ce qui plaide pour le développement maison
Il est juste d’exposer aussi l’autre côté. Une solution toute faite coûte de l’argent chaque mois, tant qu’elle tourne. On dépend d’un fournisseur et de sa planification, où ses propres souhaits côtoient ceux des autres clients. Et avant de se lancer, il faut clarifier comment récupérer ses propres données en cas de changement. Qui accorde plus de poids à ces points et dispose du temps nécessaire à la maintenance peut, à bon droit, construire soi-même, de préférence là où aucune donnée client n’est en jeu.
Ce que contient une solution qui a mûri
Une solution achetée n’est pas non plus exempte d’erreurs. La différence réside dans qui trouve les erreurs et qui les corrige. Sur une plateforme, des collaborateurs de nombreuses entreprises travaillent chaque jour. Les processus sont ainsi testés en conditions réelles, les signalements d’erreurs arrivent chez le fournisseur et sont corrigés, pour tous les clients en même temps. Le fournisseur en vit, il a donc toutes les raisons d’être rapide. Bien des maladies de jeunesse qu’un programme maison doit encore traverser y sont déjà guéries.

Une plateforme intègre le savoir de nombreuses entreprises. Qui développe pour de nombreux ateliers de pierre examine les processus de près et cherche comment les accélérer fondamentalement. Pour une entreprise isolée, il n’y a guère de sens à refaire ce travail seule. L’important est que la solution se paramètre de manière flexible, afin qu’une petite entreprise y retrouve aussi ses propres processus. Chez DDL, utilisé par des ateliers de pierre depuis 2020, chaque dalle est gérée comme une pièce unique avec photo, dimensions et bloc, les chutes retournent en stock comme de nouvelles dalles, et quiconque propose une dalle réservée reçoit un avertissement.
La meilleure voie : se connecter plutôt que reconstruire
L’IA reste un outil puissant lorsqu’elle est utilisée au bon endroit. Il est utile de se pencher tôt sur deux questions.
Où puis-je connecter mes propres programmes ? Les données qui doivent être justes se trouvent dans un système éprouvé. Les petits outils maison s’y raccordent, par exemple une analyse pour la direction ou un affichage pour le site web de l’entreprise. Si un tel outil tombe en panne, l’entreprise continue de tourner dans le système éprouvé. DDL dispose pour cela d’une interface ; l’accès est mis en place par DDL.
Dois-je vraiment construire cela moi-même ? Beaucoup de besoins d’une entreprise sont partagés par d’autres. Il vaut la peine de demander d’abord au fournisseur s’il prévoit de toute façon une telle fonction pour tous. Il l’entretient alors, et elle fonctionne encore après la prochaine mise à jour.
Qui a déjà construit quelque chose en retient l’essentiel : ce que le développement maison a révélé sur les processus de l’entreprise est la meilleure préparation à toute solution. Jan Keller, expert du secteur chez DDL, l’examine volontiers ensemble, sur le stock et le projet de l’entreprise elle-même.
| Fraunhofer IESE | Vibe Coding verstehen: Definition, Potenziale und Risiken des KI-Trends |
| Chroma, 2025 | Context Rot: How Increasing Input Tokens Impacts LLM Performance |
| GitClear, 2025 | AI Copilot Code Quality |
| Veracode, 2025 | GenAI Code Security Report |
| Lovable, 2025 | Statement on CVE-2025-48757 |
| METR, 2025/2026 | Étude du 10/07/2025 et mise à jour du 24/02/2026 |
| DIBt | BauPVO 2024 seit 8. Januar 2026 anwendbar (Règlement Produits de construction 2024 applicable depuis le 8 janvier 2026) |
Découvrir les solutions DDL
Solution maison ou plateforme ?
Jan Keller examine ensemble ce dont le stock de l’entreprise a besoin et où des outils maison peuvent se connecter à DDL.