Pratiques d'ingénierie IA
Deux volets : l'IA dans le développement logiciel de vos équipes TI, et des outils d'IA pour les métiers. Chacun vient avec ses règles d'usage et ses points de contrôle.
Deux volets · développement logiciel (SDLC) · lignes d'affaires
- Format
- Deux volets, en ateliers et en accompagnement sur votre cas
- Avec qui
- Vos équipes de développement et les responsables des lignes d'affaires
- Vous repartez avec
- Des outils et des règles d'usage approuvés, pour le code comme pour les métiers
- Ensuite
- La formation des équipes, ou une preuve de concept sur un cas précis
À qui s'adressent les pratiques d'ingénierie IA
Ces pratiques visent les organisations dont les équipes utilisent déjà l'IA pour produire du code ou des outils, chacune à sa manière, sans que la TI ait fixé de règles communes.
- Vos développeurs utilisent des assistants de code selon leurs habitudes, sans règles communes sur les outils ni les dépôts.
- Les revues de code s'engorgent, parce que l'IA multiplie les changements à relire.
- Des métiers construisent leurs propres automatisations et assistants dans leur coin, hors de la vue de la TI.
- Vous craignez que du code source ou des données internes quittent l'organisation par un outil que personne n'a approuvé.
L'IA dans votre cycle de développement (SDLC)
Accélérer vos équipes de développement en gardant le contrôle du code.
- Cartographier le cycle : spécification, code, tests, revue et déploiement : où l'IA intervient, et où une personne décide.
- Choisir les outils et fixer les règles : assistants de code, accès aux dépôts, données qu'on peut leur envoyer.
- Garder la maîtrise du code : revue humaine, tests automatisés et journal des changements avant toute mise en production.
Des lignes d'affaires outillées
Laisser foisonner les idées et les solutions sans compromettre la sécurité ni la performance de l'organisation.
- Recenser les besoins des métiers : automatisations, assistants et outils internes que les équipes veulent construire ou adopter.
- Poser un cadre sûr : outils approuvés, accès aux données, validation de sécurité avant l'usage.
- Suivre la performance : ce que les outils coûtent et la charge qu'ils font peser sur vos systèmes.
Des règles communes pour l'IA dans le développement logiciel
Pour les équipes de développement, on commence par cartographier le cycle : spécification, code, tests, revue, déploiement. À chaque étape, on note où l'IA intervient déjà, où elle pourrait aider et où une personne doit rester seule à décider. Les règles qui en découlent portent sur les outils approuvés, les dépôts qu'ils peuvent lire et les données qu'on peut leur envoyer. La revue humaine, les tests automatisés et le journal des changements restent en place avant toute mise en production, car l'IA fait grossir le volume de code à contrôler.
Pour les lignes d'affaires, le point de départ est différent : on recense ce que les équipes veulent déjà construire, puis on pose un cadre dans lequel elles peuvent le faire. Un outil approuvé, un accès encadré aux données et une validation de sécurité avant l'usage remplacent à la fois l'interdiction générale et le laisser-faire. On suit aussi ce que coûte chaque outil et la charge qu'il fait peser sur vos systèmes, pour que le succès d'un outil ne surcharge pas ceux des autres.
Ce que vous obtenez
Un cycle de développement outillé
Une carte de votre cycle, de la spécification au déploiement, qui indique où l'IA intervient, quels outils sont approuvés et où une personne relit et valide avant la suite.
Des outils approuvés pour les métiers
Une liste d'outils d'IA autorisés pour les lignes d'affaires, avec les accès aux données qu'ils peuvent avoir et la validation de sécurité à passer avant de s'en servir.
Des règles d'usage vérifiables
Des règles écrites et des points de contrôle qui laissent les idées circuler sans exposer la sécurité ni la performance, avec un suivi des coûts et de la charge sur vos systèmes.
Après les pratiques d'ingénierie IA, former puis éprouver
Des règles ne servent que si les équipes les appliquent : la formation les transmet aux développeurs, aux métiers et à leurs référents. Pour un cas précis, par exemple un assistant destiné à une ligne d'affaires, la preuve de concept vérifie sur vos données que l'outil tient ses promesses avant son déploiement élargi.
Questions fréquentes
L'IA dans le développement veut-elle dire laisser le code à l'IA ?
Non. Le premier volet vise à accélérer vos équipes en leur laissant le contrôle du code : une personne relit et valide ce qui entre dans vos dépôts, les tests s'exécutent avant la mise en production et chaque changement reste traçable.
Pourquoi outiller les lignes d'affaires et pas seulement la TI ?
Les métiers connaissent les tâches qui valent d'être automatisées, et leurs idées n'attendent pas toujours la TI. Le second volet leur donne un cadre, avec des outils approuvés et des règles d'accès aux données, pour que ces idées voient le jour sans mettre en risque la sécurité ni la performance de l'organisation.
Faut-il prendre les deux volets ensemble ?
Non, ils se prennent séparément. Le volet développement s'adresse à vos équipes TI, le volet lignes d'affaires aux métiers qui veulent leurs propres outils. L'audit indique par lequel commencer.
Quels dépôts et quelles données un assistant de code peut-il voir ?
Cela se décide outil par outil, et non selon les habitudes de chacun. Le volet développement fixe les outils approuvés, les dépôts auxquels ils accèdent et les données qu'on peut leur envoyer. Pour le code le plus sensible, le choix entre modèle infonuagique et modèle privé se travaille avec la gouvernance.