Accueil · IA
Delivery IA et gouvernance
Construire avec l'IA est devenu la partie facile
Un ingénieur expérimenté équipé d'une IA produit aujourd'hui en une semaine ce qui demandait un trimestre. Ce qui n'a pas changé : qui décide des règles, qui relit ce qui sort, et qui en répond en production. C'est dans cet écart que se fabrique la prochaine dette technique, et c'est la partie sur laquelle nous travaillons.
Notre position
Un delivery IA sans gouvernance coûtera plus cher que les vagues précédentes
Chaque accélération logicielle antérieure, des langages de quatrième génération au low-code, a produit le même schéma : le volume produit a augmenté plus vite que la capacité à le relire, et l'écart s'est transformé en coût de maintenance trois ans plus tard. Le développement assisté par IA suit la même courbe, avec deux différences qui l'alourdissent. Le volume est plus important, et celui qui a produit le code ne sait pas toujours expliquer pourquoi il est écrit ainsi.
Ce que nous observons sur les projets réels, ce n'est pas que le code soit mauvais. C'est que rien ne le contraint. Deux ingénieurs sur la même base, qui sollicitent le même modèle la même semaine, produisent des écrans qui se comportent différemment, des nommages qui divergent et des motifs que personne n'a choisis. Laissée seule un trimestre, une équipe se retrouve avec un système qui fonctionne et sur lequel plus personne ne sait raisonner.
La seconde défaillance est plus lente et plus difficile à corriger. Un système d'IA lit ce que votre organisation stocke. Si la donnée est périmée, dupliquée ou non documentée, le résultat se dégrade, et ce résultat est à son tour stocké puis relu par l'itération suivante. Les erreurs deviennent la source. La gouvernance de la donnée n'est pas un chantier parallèle à un programme d'IA, c'est ce qui empêche le programme de se déliter.
Ce qui se passe réellement
Quatre défaillances, dans cet ordre
- La divergence, en quelques semainesSans convention écrite que le modèle est contraint de relire, la production dérive. Les écrans cessent de se ressembler, le même concept prend trois noms, et le coût retombe sur celui qui maintiendra. La correction est peu coûteuse au départ et onéreuse après le quatrième module.
- Du code en production que personne n'a reluLa question n'est pas de savoir si un modèle écrit du bon code. Elle est de savoir si une organisation peut dire qui a relu quoi avant que cela n'atteigne un système qui déplace de l'argent ou des marchandises. La plupart ne le peuvent pas, et leur audit interne n'a pas encore posé la question.
- Une dette de sécurité qui arrive sans bruitLe code généré embarque des librairies, et les librairies portent des vulnérabilités. Sans analyse dans la boucle, un projet hérite d'un arbre de dépendances que personne n'a choisi et que personne ne surveille. C'est mécanique à résoudre, et presque jamais mis en place au démarrage.
- La boucle de dégradation de la donnéeCe que produit le modèle redevient une entrée. Sans fraîcheur, sans lignage et sans propriétaire sur la donnée sous-jacente, la qualité baisse au fil des itérations, et la baisse reste invisible jusqu'à ce qu'une décision métier soit visiblement fausse.
Depuis notre propre delivery
Dix ans d'outillage interne reconstruits en prototype en deux mois
L'un de nos consultants seniors, présent depuis des années sur la plateforme d'intégration d'un armateur mondial de conteneurs, en a reconstruit toute la console d'exploitation avec l'assistance d'une IA : gestion des paramétrages, versionnage, contrôle qualité, packaging, édition graphique des workflows et supervision de production. Frontend, backend, procédures de base de données et API. Deux mois, une personne.
Il avait passé des années dans le modèle de données de la plateforme, ses règles métier et ses modes de panne. Interrogé sur la capacité d'un développeur extérieur à faire de même avec les mêmes outils, sa réponse a été non : les outils étaient à la portée de tous, le contexte non.
Chaque écran validé a produit une règle, consignée dans la documentation du projet plutôt que laissée dans un historique de conversation. Le modèle relit cette documentation avant de toucher à l'écran suivant, et c'est ce qui fait que vingt écrans ressemblent à un seul produit.
Versionnage adressé par empreinte, objets livrés rendus immuables, et un contrôle qualité qui bloque le packaging quand les règles ne sont pas respectées. Une bonne pratique que l'on peut contourner est une suggestion. La même règle dans la chaîne est un contrôle.
Analyse statique, détection de secrets, suivi des dépendances et de la couverture dans un conteneur, rapport réinjecté pour correction, puis une seconde revue menée depuis un contexte vierge, sans historique du projet. Une CVE sur une dépendance et un défaut d'accès concurrent ont été trouvés et corrigés ainsi.
Ce système est un prototype en test, pas un déploiement en production, et il n'a pas encore été soumis à la revue de sécurité du client. Nous le décrivons pour ce qu'il montre de la méthode, pas pour revendiquer une référence en production. Le client n'est pas nommé.
Comment nous intervenons
Nous construisons la solution, et le cadre dans lequel elle tourne
L'essentiel de ce travail ne porte pas sur le modèle. Il porte sur l'échafaudage technique et organisationnel qui permet à une équipe d'aller vite avec l'IA sans produire quelque chose que personne ne pourra maintenir, auditer ni défendre.
Cadrage du delivery IA
Conventions, nommage, règles d'architecture et definition of done, rédigés comme une documentation que le modèle est contraint de relire plutôt que comme une planche que personne n'ouvre. Et l'arbitrage de ce qui est délégué à un modèle et de ce qui ne l'est pas.
- Conventions
- Règles d'architecture
- Definition of done
- Discipline de contexte
Revue et sécurité du code généré
Analyse statique, détection de secrets, suivi des dépendances et des vulnérabilités, seuils de couverture, et une seconde revue contradictoire menée depuis un contexte vierge. Mise en place comme une chaîne, pas comme un audit ponctuel.
- SAST
- Détection de secrets
- SCA et CVE
- Revue contradictoire
Architecture et intégration de la solution
La part qui décide si un prototype devient un système : modèle de données, API, packaging, environnements, migration et interfaces avec ce que vous exploitez déjà. Notre métier fondateur, appliqué aux constructions assistées par IA.
- Modèle de données
- Conception d'API
- Packaging et environnements
- Intégration au legacy
Gouvernance de la donnée pour l'IA
Fraîcheur, lignage, propriété et données de référence sur les flux qu'un système d'IA consomme, avec des engagements explicites sur l'âge de la donnée et le taux d'erreur. C'est ce qui empêche la qualité de se dégrader au fil des itérations.
- Engagements de fraîcheur
- Lignage
- Données de référence
- Supervision qualité
Conformité et souveraineté
Où tournent les modèles, où la donnée réside et transite, ce qu'un système d'IA a le droit de lire, et les preuves qu'un régulateur ou un audit interne réclamera. Sous AI Act, DORA et NIS2, avec une option d'hébergement européen quand le périmètre l'exige.
- AI Act
- DORA et NIS2
- Hébergement européen
- Preuves d'audit
Montée en compétence des équipes
La compétence qui compte désormais n'est pas le framework. C'est de connaître le métier assez bien pour juger ce que le modèle a produit. Nous travaillons aux côtés de vos ingénieurs, nous transférons la méthode, et nous laissons les conventions derrière nous.
- Delivery en binôme
- Transfert de méthode
- Pratique de revue
- Documentation
Comment nous nous engageons
Commencer sur un périmètre réel, pas sur une politique
5 à 15 jours. Ce que vos équipes construisent déjà avec l'IA, ce qui arrive en production, ce qui est relu, et où se situe l'exposition. Se termine par un plan chiffré.
Conventions, chaîne de revue et barrières qualité sur un périmètre réel, pour que les règles soient éprouvées sur du delivery plutôt qu'écrites dans l'abstrait.
Une solution bornée, livrée avec l'assistance de l'IA, à l'intérieur de ce cadre, avec le travail d'architecture et d'intégration qui la rend maintenable.
Vos ingénieurs tiennent la méthode sans nous. Conventions, chaîne et documentation vous restent.
Vos équipes construisent déjà avec l'IA.
La question est de savoir ce que devient ce code dans dix-huit mois. Un assessment de 5 à 15 jours vous dit où vous en êtes et ce que coûtera la mise en place d'un cadre.