Construire des bâtisseurs d'IA : Guide pratique pour combler l'écart entre connaissances et capacités en IA

Le plus grand obstacle à l'adoption de l'IA n'est pas la sensibilisation. C'est l'écart entre parler de l'IA et construire avec elle.

Les professionnels dont le rôle principal n'est pas d'écrire du code, mais dont le travail quotidien dépend de plus en plus de solutions d'IA, n'ont pas besoin d'un parcours en ingénierie pour commencer à développer des capacités en IA. Ils ont besoin des bons outils, d'un soutien structuré et de la permission d'échouer. Voici comment nous l'avons prouvé, et comment vous pouvez le reproduire.

Le problème que les organisations ignorent

Vos équipes participent déjà à des conversations sur l'IA, qu'elles répondent aux questions des clients, évaluent des solutions de fournisseurs ou identifient des opportunités d'automatisation dans leurs responsabilités quotidiennes. Compte tenu de la vitesse à laquelle les outils d'IA agentique sont devenus généralement disponibles, la plupart d'entre eux n'ont jamais rien construit avec les outils dont ils parlent.

Ces équipes, qu'elles soient dans les ventes, les opérations, la finance ou le produit, ont regardé les démonstrations et obtenu les certifications. Mais quand quelqu'un demande : « comment cela fonctionne-t-il réellement ? », elles n'ont pas la réponse qui vient de l'avoir construit elles-mêmes.

Le coût est réel : adoption plus lente, gains de productivité retardés, opportunités d'identifier des cas d'usage manquées, et un fossé croissant entre ce que vos équipes savent sur et ce qu'elles peuvent mettre en œuvre.

Nous avons interrogé des professionnels du métier, des personnes qui utilisent des outils d'IA quotidiennement mais qui n'écrivent pas de code de production, sur ce qui les freinait dans l'adoption de l'IA. La réponse n'était pas « je ne veux pas apprendre ». 90 pour cent voulaient une expérience pratique de construction d'agents d'IA. Il leur manquait le tissu conjonctif et l'échafaudage nécessaires pour construire en toute sécurité. Le graphique suivant illustre les obstacles les plus courants auxquels les équipes métier sont confrontées lorsqu'elles tentent de construire avec l'IA.

Figure 1 : Principaux obstacles cités par les équipes métier pour construire avec l'IA

À un niveau général, elles pouvaient parler d' Amazon Bedrock et d' Amazon Bedrock AgentCore, une plateforme pour construire, connecter et optimiser des agents à grande échelle avec n'importe quel framework ou modèle (80 pour cent l'avaient explorée). Mais moins de 1 sur 5 avait touché à Strands Agents SDK ou construit avec des agents AWS Lambda . Elles renonçaient aux hackathons et aux événements de construction parce qu'elles ne croyaient pas que leurs connaissances techniques étaient assez solides pour rivaliser aux côtés des ingénieurs.

Pour résoudre ce problème, nous avons conçu un programme structuré de six semaines qui associe des professionnels du métier à des mentors et à des outils de qualité production pour construire des prototypes d'IA fonctionnels capables de s'étendre au-delà du programme. L'objectif : combler l'écart entre les connaissances conceptuelles et les capacités pratiques.

Ce qu'une équipe a construit : la preuve en six semaines

Quatre professionnels en contact avec les clients qui n'avaient jamais travaillé ensemble ont participé à notre programme. Aucun n'avait de parcours en ingénierie. Six semaines plus tard, ils ont présenté leur prototype, WealthWise, un outil de conseil financier en IA multi-agents, qui a remporté la première place.

Ce qu'ils ont construit :

• Cinq agents d'IA spécialisés fournissant des conseils financiers intelligents : analyse de portefeuille, évaluation des risques, planification financière, analyses de marché et recommandations d'investissement personnalisées.
• Architecture à double serveur (Node.js + Python Flask) avec les modèles Amazon Nova.*
• Strands Agents SDK pour l'orchestration multi-agents et la mémoire de conversation.
• Quatre tables Amazon DynamoDB pour la persistance des données en temps réel.
• Intégration de données de marché en direct pour des recommandations financières tenant compte du contexte.
• Temps de réponse inférieurs à 5 secondes pour le raisonnement financier complexe.

Le système présente une prise de décision coordonnée : chaque agent décide indépendamment des outils à invoquer et enchaîne plusieurs outils, réalisant un raisonnement multi-étapes à travers les données de portefeuille, les bases de données de marché et les modèles de planification financière.

Ils ont attribué leur réussite à cinq principes établis dès le premier jour :

1. Apprendre plutôt que gagner – Choisir des approches difficiles plutôt que des raccourcis sûrs leur a permis d'expérimenter sans crainte.
2. Cadences régulières – Les standups quotidiens ont prévenu l'isolement et permis de détecter les problèmes tôt.
3. Commencer par un Produit Minimum Viable (MVP), puis affiner – Un flux fonctionnel de bout en bout dès le Jour 2, puis itérer.
4. Participer aux heures de permanence – Rechercher activement du mentorat en cas de blocage.
5. S'amuser – La sécurité psychologique avant la production technique.

Les participants ont témoigné de la manière dont le format pratique a accéléré leur apprentissage :

« Le moment du hackathon était parfait, et le format pratique s'est révélé inestimable pour l'enablement d'AgentCore – accélérant ce qui aurait pu être une longue courbe d'apprentissage. »

« Excellent projet de teambuilding et d'apprentissage de l'IA ! J'ai beaucoup appris en autonomie et j'ai désormais plus d'empathie pour les clients qui découvrent les solutions d'IA. »

* Les modèles Amazon Nova sont disponibles sur Amazon Bedrock dans certaines régions AWS. Pour connaître les dernières disponibilités, consultez la page AWS Regional Services.

Le guide pratique : comment nous avons conçu le programme

Les sections suivantes détaillent la structure du programme, chaque phase et les décisions de conception qui ont fait son succès.

Structure du programme

Le programme se déroule sur six semaines, les participants consacrant environ quatre heures par semaine. Nous l'avons structuré délibérément ainsi : d'après les données de notre programme, les participants ayant suivi un programme par phases ont retenu trois fois plus de compétences pratiques que ceux des formats intensifs de deux jours. Les professionnels dont le travail principal n'est pas d'écrire du code ont besoin de cycles d'itération : du temps pour lutter avec des concepts inconnus, récupérer, et reconstruire avant que la confiance ne devienne durable.

Phase 0 : Recrutement et mise en place du programme

Nous avons recruté les participants par nomination des managers, via Slack et par campagnes d'e-mails, en ciblant des professionnels qui utilisent quotidiennement des solutions d'IA sans les construire : gestionnaires de comptes, consultants solutions, analystes opérationnels, chefs de programme et rôles similaires. L'adhésion de la direction est venue en premier. Nous avons informé les responsables d'équipe de l'engagement de temps (quatre heures par semaine pendant six semaines) et l'avons présenté comme un investissement dans la fluidité et la qualité des conversations, et non comme une distraction par rapport à leur livraison quotidienne.

Le programme a été orchestré par quatre membres d'une équipe centrale plus des mentors qui l'animaient en parallèle de leur travail quotidien. C'est un point clé de reproductibilité : cela ne nécessite pas d'équipe de programme dédiée, mais cela exige au moins une personne disposant d'une confiance organisationnelle suffisante pour protéger le temps des participants.

Phase 1 : Constitution des équipes et lancement

Ce que font les participants : Ils forment des équipes de 3–4 personnes avec des niveaux d'expérience volontairement mixtes. Les équipes définissent un énoncé de problème lié à un scénario réel rencontré dans leur fonction.

Ce que cela produit : Un concept de projet délimité pouvant être présenté en démonstration et une structure de responsabilité au sein de l'équipe.

Pourquoi c'est important avant de continuer : Sans problème concret à résoudre, les sessions de formation deviennent abstraites. Les équipes qui définissent d'abord leur cas d'usage cible absorbent le contenu technique avec un objectif.

Phase 2 : Formation

Ce que font les participants : Ils assistent à des sessions de formation en direct sur les concepts de l'IA agentique et les outils AWS. Ce ne sont pas des cours magistraux. Les participants travaillent dans les outils mêmes qu'ils utiliseront pendant la phase de construction, en réalisant des exercices structurés qui reflètent leur travail de projet.

Ce que cela produit : Une fluidité technique de base et un environnement local fonctionnel.

Pourquoi c'est important avant de continuer : Les équipes qui passent directement à la construction se heurtent à un mur lors de la configuration de l'environnement et des concepts fondamentaux. Cette phase évite le point d'abandon le plus fréquent.

Phase 3 : Idéation, construction et développement

Ce que font les participants : Ils conçoivent et itèrent sur des prototypes fonctionnels sur plusieurs semaines. Chaque équipe est associée à un mentor techniquement compétent qui offre un filet de sécurité, débloquant les problèmes d'infrastructure et suggérant des modèles d'architecture sans faire le travail à leur place.

Ce que cela produit : Un prototype fonctionnel qui pourrait être présenté à une partie prenante ou à un client.

Pourquoi c'est important avant de continuer : Le calendrier étendu permet 2–3 cycles d'itération. Les équipes qui avaient construit un prototype en semaine 3 ont eu le temps d'appliquer continuellement les nouveaux apprentissages, de tout démonter et de reconstruire mieux en semaine 5. C'est dans cette itération que le véritable apprentissage se produit.

Phase 4 : Évaluation et démonstrations

Ce que font les participants : Ils réalisent des démonstrations en direct évaluées selon cinq catégories : Business Impact, Technical Excellence, Reusability and Scalability, Innovation, et Presentation Quality.

Ce que cela produit : Une preuve de capacité validée par les pairs et une bibliothèque de prototypes réutilisables.

Pourquoi c'est important : Le format démo reflète ce que les participants feront lors de véritables conversations avec des clients, des dirigeants et des partenaires interfonctionnels. Les critères d'évaluation rappellent que fonctionner ne suffit pas. Il faut que ce soit percutant, évolutif et clairement communiqué.

Décisions de conception critiques

Le choix des outils est la décision la plus importante pour les constructeurs qui ne sont pas ingénieurs. Les mauvais outils créent des frictions qui bloquent la dynamique. Les bons abstraient l'infrastructure et rencontrent les gens à leur niveau actuel d'expertise. Nous avons choisi :

• Kiro Environnement de développement intégré (IDE) pour le développement en langage naturel : décrivez ce que vous voulez, et il échafaude l'architecture.
• Amazon Bedrock pour des modèles de fond accessibles via API dans cette Région : aucune expertise en apprentissage automatique (ML) n'est requise pour obtenir une réponse fonctionnelle d'un modèle.
• Strands Agents SDK pour des schémas d'agents composables : les agents se composent comme des blocs de construction.
• Serveurs AWS Model Context Protocol (MCP) et agents AWS Lambda pour orienter les équipes vers des architectures déployables et prêtes pour la production, et pas seulement des notebooks locaux.

Le principe fondamental n'a jamais changé : construire quelque chose de réel que vous pourriez démontrer à bref délai.

Gérer la perturbation du travail quotidien

Nous avons volontairement plafonné l'engagement hebdomadaire à quatre heures et donné aux participants une flexibilité sur le moment où ces heures avaient lieu. Le retour le plus fréquent était que les participants appliquaient ce qu'ils apprenaient directement à leur travail dès les deux premières semaines, ce qui rendait l'investissement en temps complémentaire plutôt que concurrentiel.

Les résultats

Le graphique suivant compare les auto-évaluations des participants avant et après le programme sur huit indicateurs clés, notamment la compétence en IA, l'adoption des outils et la préparation à appliquer les apprentissages avec les clients.

Figure 2 : Auto-évaluations des participants avant et après le programme

Au départ, les participants citaient « le manque d'exemples concrets » comme principal obstacle à la création avec l'IA. À l'arrivée, 23 points de pourcentage (pp) de participants de plus se jugeaient confiants dans l'application de l'IA à des cas d'usage pratiques qu'ils ne s'y attendaient au début. Les participants ont quitté le programme avec un prototype fonctionnel, un dépôt de code et une architecture de référence qu'ils pouvaient présenter immédiatement aux parties prenantes.

Ce qu'ils ont construit et ce qu'ils apportent aux clients :

• Coordination des soins multi-agents pour les éditeurs de logiciels indépendants (ISV) du secteur de la santé.
• Systèmes de modération et de triage de contenu.
• Identification et prévention de la fraude.
• Prédiction et prévention de l'attrition des clients.
• Orchestration multi-agents pour la prise de décision autonome.
• Démonstrations Kiro + Amazon Bedrock AgentCore pour les ateliers clients.

L'impact : d'observateurs à bâtisseurs

Lorsque nos participants ont obtenu un accès pratique aux outils d'IA, ils sont passés de la discussion des possibilités à la construction de prototypes fonctionnels. Les chiffres racontent l'histoire :

• Auto-évaluation de la compréhension de l'IA agentique comme « forte ou experte » : augmentée de 27 pour cent à 82 pour cent (+55 pp).
• Sentiment d'être « bien ou extrêmement préparé » à identifier les opportunités d'IA : augmenté de 41 pour cent à 85 pour cent (+44 pp).
• Participants ayant uniquement une expérience théorique ou limitée : réduits de 34 pour cent à 0 pour cent (éliminés).

Voici ce que cet investissement débloque :

Pour vos équipes : Elles cessent d'être des observateurs de l'IA et deviennent des bâtisseurs d'IA. Elles savent ce qui est faisable, ce qui est coûteux et ce qui peut se construire en un week-end grâce à l'expérimentation directe. Dans notre cohorte, 52 pour cent ont identifié des clients spécifiques qui pourraient bénéficier de ce qu'ils avaient construit pendant le programme, et 87 pour cent comptaient appliquer leurs apprentissages avec des clients dans les 30 jours. Le programme a dépassé les attentes en matière de cas d'usage pratiques parce qu'il exigeait qu'ils créent eux-mêmes les exemples.

Pour vos organisations d'ingénierie : Quand les contreparties métier peuvent prototyper et articuler les compromis d'architecture, les équipes d'ingénierie passent moins de temps à traduire les exigences et plus de temps à construire. Les bâtisseurs techniques bénéficient d'un recueil des besoins plus clair, de moins de demandes mal alignées et de partenaires capables d'éprouver la faisabilité avant qu'un seul sprint ne soit engagé. Considérez ceci : 82 pour cent des participants sont repartis avec une solide compréhension de l'architecture de l'IA agentique. La maîtrise des outils a bondi dans toute la pile : Strands Agents SDK est passé de 20 pour cent à 80 pour cent d'adoption (+60 pp) et AgentCore de 39 pour cent à 85 pour cent, relevant le niveau de jugement en ingénierie.

Pour vos clients : Ils bénéficient de partenaires qui ont navigué les mêmes compromis architecturaux qu'ils rencontrent, grâce à une expérience directe et pratique. Les conversations passent de « je vous recontacte » à des démonstrations en direct. Avant le programme, 44 pour cent des participants citaient l'incertitude sur les modèles d'architecture comme un obstacle. Après le programme, 90 pour cent se sentaient bien préparés ou mieux pour identifier les opportunités d'IA dans de véritables conversations avec les clients.

Pour votre organisation : Vous obtenez un modèle reproductible qui se cumule. L'expansion de notre pilote d'une équipe à un déploiement régional puis désormais mondial illustre le schéma : la maîtrise pratique se met elle-même à l'échelle. Le programme a atteint un taux de recommandation de 100 pour cent, avec 95 pour cent des participants déclarant que le programme a répondu aux attentes ou les a dépassées.

Sept leçons pour reproduire cela dans votre organisation

Ces sept leçons capturent ce qui a fait le succès du programme et ce qu'il faut reproduire dans votre propre organisation.

1. Le choix des outils change tout

Les expériences agentiques low-code suppriment l'obstacle du « je ne suis pas assez technique ». C'est une décision de conception de programme, pas une réflexion d'achat après coup. Si vos outils exigent la maîtrise de Python, vous avez perdu la moitié de la salle avant même la première semaine.

2. La structure l'emporte sur l'intensité

Un programme échelonné (6 semaines) avec des jalons clés donne de meilleurs résultats auprès d'un public non technique qu'un sprint de deux jours. Attendez-vous à ce que la première semaine paraisse lente. L'effet cumulatif vient ensuite.

3. Le mentorat est le multiplicateur

Jumeler les participants non techniques avec des mentors compétents sur le plan technique élimine la peur de l'échec et accélère l'apprentissage. Le mentor ne construit pas à leur place. Il fournit un filet de sécurité.

4. Construire quelque chose de réel

Exiger des prototypes fonctionnels avec des dépôts de code et des architectures de référence (pas des diapositives) force un engagement profond avec les outils. On ne peut pas tricher pendant une démonstration en direct. C'est ce qui distingue un hackathon d'une formation.

5. Mesurer avant et après

Des évaluations de compétences avant et après rendent l’impact visible et construisent l’argumentaire en faveur de l’expansion. La confiance auto-déclarée est utile, mais c’est le passage d’une expérience pratique « limitée » à « étendue » qui compte.

6. Rendre le modèle réplicable

Un guide bien documenté (consignes pour les participants, grilles d’évaluation, cadres d’association des mentors, guides de configuration de l’environnement) transforme un événement ponctuel en un programme évolutif.

7. Créer d’abord un climat de sécurité psychologique

Lorsque les gens n’ont pas peur d’échouer, ils construisent des choses qu’ils ne pensaient jamais possibles. L’équipe gagnante a cité « apprendre plutôt que gagner » comme premier principe. Chaque équipe qui a prospéré a établi la confiance avant le code.

Commencer

Le guide, les grilles d’évaluation et les guides de configuration de l’environnement sont disponibles pour les équipes souhaitant reproduire ce modèle. Contactez l’un des auteurs pour en savoir plus sur l’adoption de ce cadre dans votre organisation.

En savoir plus sur Amazon Bedrock | Kiro IDE | Strands Agents SDK

À propos des auteurs