Il y a encore quelques mois, l’enjeu était de faire passer les projets d’IA du pilote à la production. 
Avec l’essor des agents, les entreprises abordent une nouvelle étape, qui soulève d’autres difficultés : besoins mal définis, outils qui se multiplient, retour sur investissement surestimé, agents insuffisamment encadrés ou validation humaine négligée.

Georges Harb, Vice-Président Senior en charge de la stratégie IA et des Business Solutions, revient sur dix écueils fréquemment rencontrés dans les projets IA et partage des pistes pour les éviter.

1. Ne pas partir du besoin

C’est sans doute l’écueil le plus classique : décider de « faire de l’IA » avant même d’avoir clairement identifié le problème à résoudre. Il faut d’abord partir des irritants rencontrés et des objectifs à atteindre. Ce n’est qu’ensuite que l’on peut déterminer si l’IA est réellement la meilleure réponse. Dans certains cas, une automatisation classique ou l’évolution d’un outil existant apporteront davantage de valeur, pour moins de complexité, avec des coûts et un impact environnemental potentiellement plus faibles.  

2. Confondre prototype et produit

L’IA permet aujourd’hui de créer une interface ou une application en quelques heures. C’est un excellent moyen de matérialiser rapidement une idée, de tester un concept ou d’alimenter la discussion avec un client. Mais ce n’est encore qu’un prototype. Le passage en production change complètement d’échelle. Il faut alors traiter l’architecture, la sécurité, les tests, l’observabilité, la maintenabilité ou encore l’intégration avec le système d’information existant.

3. Sous-estimer les tests 

Produire davantage de code ne signifie pas produire un meilleur logiciel. Les outils d’IA peuvent aussi générer un code difficile à maintenir voire de la dette technique. Le testing doit donc être intégré dès la conception du projet, et non ajouté à la fin. À cela s’ajoute aussi  la nécessité de contrôler les comportements propres aux modèles d’IA.

L’enjeu n’est pas seulement de développer plus vite. Il faut aussi être capable de maintenir et de faire évoluer l’application dans la durée.  

4. Réduire l’IA à la génération de code 

Le développement est souvent la partie la plus visible des usages de l’IA. Mais son potentiel va bien au-delà. Elle peut servir à synthétiser des entretiens utilisateurs, comparer des parcours, préparer des spécifications, imaginer des cas limites, produire des données de test, analyser des anomalies ou documenter un patrimoine applicatif ancien. Plus largement, l'IA peut aussi amener à repenser les processus métier eux-mêmes. Pourquoi accélérer le développement d'une application si l'IA permet de réaliser directement certaines tâches auxquelles elle était destinée ? 

5. Empiler les outils sans regarder l’existant 

La facilité avec laquelle il est possible de tester de nouveaux modèles, agents ou applications peut vite conduire à leur multiplication. Cette diversité est utile pour explorer de nouvelles possibilités et comparer les approches. Mais sans vision d'ensemble, ce foisonnement risque surtout d’ajouter de la complexité au système d’information. Le choix d’un outil doit être guidé par le contexte de l’entreprise, jamais par la préférence d’une équipe ou par la nouveauté du produit.  

6. Traiter le juridique et la conformité « à la fin » 

Une solution peut être techniquement convaincante et néanmoins impossible à utiliser en production : 

  • Le contrat avec le client peut interdire certains usages.
  • Des données peuvent ne pas être autorisées à sortir d'un environnement donné.
  • Un outil peut ne pas respecter les règles internes de sécurité ou de confidentialité.

Ces questions doivent donc être traitées en parallèle des développements, dès les premières phases du projet. Chez CGI, nous formalisons cette démarche dans nos projets à travers le contrôle des contrats, la qualification des données, la vérification des conditions d’utilisation des solutions et l’analyse du cas d’usage au regard de l’AI Act.

7. Laisser les agents combler les zones d’ombre 

Un agent IA ne s’arrête pas nécessairement lorsqu’une information lui manque. Il peut tenter de compléter ce qu’il ne sait pas par une hypothèse plausible. Dans certains cas, notamment lorsqu’il s’agit d’une règle métier, d’un droit d’accès ou d’une exigence de sécurité, le risque peut être particulièrement sérieux. Plus un agent prend en charge une tâche large, plus le cadre qui lui est donné doit être précis. C’est notamment l’objectif du « spec-driven development » : faire de la spécification une source de vérité structurée et versionnée, qui décrit clairement les règles, les interdictions, les cas particuliers et les critères d’acceptation. 

8. Extrapoler trop vite les gains de productivité 

Les gains de productivité dépendent fortement de la qualité des données, de l’architecture existante, de la documentation, des outils utilisés et de l’expérience des équipes. Une performance obtenue sur une application moderne et bien documentée ne peut pas être appliquée automatiquement à l’ensemble d’un patrimoine informatique. D'autant que les capacités de l'IA évoluent si rapidement que les projections de productivité peuvent vite devenir obsolètes. Nos experts recommandent de travailler par scénarios (prudent, nominal et ambitieux) en explicitant les hypothèses : niveau d’adoption, proportion de tâches réellement automatisables, coûts d’intégration ou encore temps consacré au contrôle. Le ROI doit ensuite être mesuré projet par projet, puis réévalué à partir des résultats obtenus sur le terrain. 

9. Mesurer l’usage plutôt que la valeur 

Le nombre de licences déployées, de requêtes adressées à un modèle ou d’utilisateurs actifs permet de mesurer l’adoption d’un outil. Pour comprendre la valeur créée, il faut d’abord disposer d’une situation de référence, puis suivre quelques indicateurs métier : temps de traitement, délai de mise sur le marché, nombre de défauts, couverture des tests, volumes traités ou taux de reprises manuelles. Une évaluation encore rarement menée dans la durée, qui doit aussi intégrer les impacts humains et environnementaux, au-delà des seuls gains financiers. 

10. Oublier que l’humain reste responsable 

L’autonomie croissante des agents ne fait pas disparaître la nécessité de contrôler et de décider. Le niveau de validation humaine doit simplement être adapté au risque. L’objectif n’est donc pas de placer un humain derrière chaque action réalisée par une IA, mais de déterminer précisément les moments où son intervention est indispensable. La trajectoire doit maintenir l’humain dans un rôle de direction, de validation et de responsabilité.