Contexte Rubix et ambitions IA
Poser le point de départ commun : qui fait quoi aujourd'hui, ce qui tourne déjà, ce qui bloque, et ce que l'on attend de la séance.
À couvrir
Questions d'animation
En trois mots : où en est l'IA chez Rubix aujourd'hui, côté Digital, côté IT, côté Data ?
Lequel est le plus utilisé aujourd'hui ? Lequel a le plus déçu ? Pourquoi ?
Qu'est-ce qui ralentit le plus aujourd'hui : accès à la donnée, validation sécurité, outillage, compétences, budget ?
Si nous sortons avec une seule décision à 90 jours, laquelle serait la plus utile ?
Organisation cible et gouvernance Digital × IT
Comparer les modèles qui permettent de passer à l'échelle, et fixer ce que le Digital peut décider seul, avec l'IT, ou avec la Data.
À couvrir
Échelle d'autonomie encadrée (hypothèse de travail)
Consommer
Outils IA validés, usages standards.
- Digital autonome
- Charte d'usage
Configurer
Assistants, prompts, skills partagés.
- Digital autonome
- Catalogue partagé
Connecter
Connecteurs vers des données ou outils internes.
- Accord Data + IT
- Périmètre de données défini
Construire
Agents ou applications internes.
- Revue légère IT
- Environnement cadré
Industrialiser
Mise en production et run.
- IT et Data responsables
- Critères de passage
Question à poser : à quel palier se situe le Digital aujourd'hui, et lequel faudrait-il débloquer en premier ?
Modèles d'organisation à comparer
Squads mixtes
Digital, IT et Data dans la même équipe, autour d'un cas d'usage.
Fonctionne si- Sujets bien délimités
- Sponsor métier clair
Centre d'Excellence IA
Une équipe centrale qui définit, outille et accompagne.
Fonctionne si- Elle sert les équipes plutôt qu'elle ne filtre
Modèle fédéré
Standards au centre, mise en œuvre dans les équipes.
Fonctionne si- Relais identifiés dans chaque équipe
Compétences mutualisées
Un pool d'experts mobilisables à la demande.
Fonctionne si- Capacité dimensionnée
- Priorités arbitrées
Matrice de responsabilités Digital / Data / IT
Point de départ proposé par ASI. Cliquer sur une case pour changer sa valeur en séance : R, A, C, I ou vide.
R réalise · A décide, rend des comptes · C consulté · I informé
Limites de l'autonomie du Digital
Du prototype à la production
Permettre d'expérimenter vite dans un cadre sûr, puis définir quand et comment un prototype devient un service exploité.
À couvrir
Trois paliers, trois niveaux d'exigence (hypothèse de travail)
Explorer
Bac à sable, données non sensibles ou anonymisées, durée limitée.
- Valider l'utilité
- Aucune exposition à des clients
- Pas de validation lourde
Éprouver
Utilisateurs réels, périmètre restreint, données encadrées.
- Revue sécurité et données proportionnée
- Indicateurs d'usage et de qualité
- Coût suivi
Exploiter
Service supporté, supervisé, avec un responsable du run.
- Architecture conforme aux standards Groupe
- Monitoring, tests de non-régression
- Plan de réversibilité
Critères de passage à discuter
- Valeur métier démontrée
- Sponsor et utilisateurs identifiés
- Nature des données connue
- Qualité mesurée et stable
- Sécurité et conformité validées
- Coût unitaire maîtrisé
- Responsable du run nommé
- Checklist unique, pas dix circuits
- Délai de réponse engagé
- Revue par paliers, pas en continu
Question à poser : sur le dernier cas d'usage passé en production, combien de temps ont pris les validations, et lesquelles auraient pu être évitées ou raccourcies ?
Retours d'expérience et recommandations pour Rubix
Quatre sujets, environ cinq minutes chacun. Pour chaque thème : ce qui a fonctionné, ce qui a échoué, ce que nous recommandons à Rubix.
- Coexistence de plusieurs outils IA (Copilot, Claude Team, autres)
- Gouvernance des connecteurs, accès et coûts
- Base de connaissances et skills partagés entre assistants
- Protéger les données sensibles dans des environnements connectés au SI
- Droits d'accès et usages
- Rôle de la Data dans la gouvernance des cas d'usage
- Contrôle qualité des assistants dans la durée
- Tests et non-régression lors des changements de modèle
- Limiter l'effet de l'évolution rapide des technologies
- Garde-fous contre les dérives de consommation
- Maîtrise des coûts quand les cas d'usage se multiplient
- Critères Build, Buy, Embed
Questions d'animation
Arbitrage Build / Buy / Embed (grille de départ)
Développement spécifique
Plutôt si :
- Le cas d'usage est différenciant
- Les données ne peuvent pas sortir
- L'équipe sait exploiter
Solution SaaS
Plutôt si :
- Le besoin est standard
- Le délai prime
- Les garanties contractuelles sont suffisantes
Fonction native d'un outil existant
Plutôt si :
- L'outil est déjà déployé et maîtrisé
- L'usage reste dans son périmètre
- Le coût marginal est faible
Synthèse et prochaines étapes
Repartir avec des recommandations priorisées, des décisions nommées et des actions datées.
À couvrir
Décisions et actions
Les notes, cases cochées et décisions restent dans ce navigateur uniquement. Elles ne sont envoyées nulle part : pensez à copier le compte rendu en fin de séance.