Rehrig a comprimé le développement logiciel de trois ans à sept semaines

Les palettes, les bacs et l'équipement de manutention de Rehrig Pacific Company acheminent des marchandises dans les chaînes d'approvisionnement des grands détaillants et épiciers d'Amérique du Nord. Depuis 113 ans, l'entreprise fonctionne avec une mentalité manufacturière : remettre en question les hypothèses, comprendre la cause fondamentale, s'aligner sur celle-ci, puis élaborer des contre-mesures. Cette discipline se retrouve partout, de l'usine à l'organisation des TI, au service d'une mission plus grande : célébrer ses gens et leur donner les moyens de créer des solutions innovantes qui déplacent efficacement et de façon responsable les marchandises, les ressources et les idées.

Ainsi, lorsque la direction de Rehrig Pacific a donné l'orientation, en décembre 2025, selon laquelle l'intelligence artificielle deviendrait une pièce maîtresse de la stratégie de croissance de l'entreprise, l'équipe de développement de 35 personnes n'a pas couru après la dernière tendance. Elle est partie à la recherche de quelque chose qui correspondait à sa façon de penser.

L'équipe avait évalué un large éventail d'outils d'IA agentive au cours de cette période, et rien n'avait tenu. Certains étaient trop immatures. D'autres avaient une portée trop restreinte pour faire de réels progrès sur des systèmes de production. L'enthousiasme était présent dans toute l'organisation, mais sans accélération.

Puis l'équipe a découvert Kiro.

Axé sur les specs, pas sur l'intuition

L'équipe a fait très tôt un choix philosophique délibéré. La programmation intuitive (la génération rapide de code sans intention structurée) n'était pas la voie à suivre pour des systèmes de production. Rehrig Pacific s'est plutôt engagée dans le développement axé sur les specs : une réflexion approfondie en amont, des exigences cristallisées dans des fichiers de specs avant qu'une seule ligne de code ne soit générée.

Ce n'était pas une préférence arbitraire. Cela correspondait précisément à la façon dont la culture d'ingénierie de Rehrig Pacific fonctionnait déjà, ancrée dans la méthode de résolution de problèmes A3 courante en fabrication. Remettre en question les hypothèses. Identifier la cause fondamentale. S'aligner. Puis construire.

Le flux de travail des Specs de Kiro s'est intégré à cette culture comme s'il avait été conçu pour elle.

L'architecte de l'équipe a rédigé un document de mise en œuvre définissant une méthodologie de développement native pour l'IA propre à Rehrig Pacific. Ce document codifiait six phases par fonctionnalité, de la découverte des exigences à la conception, à la mise en œuvre, à la revue de code, à l'assurance qualité et à la CI/CD. Il définissait sept rôles formels, Kiro étant explicitement inscrit comme participant aux côtés des propriétaires de produit, des architectes, des développeurs et des ingénieurs en assurance qualité.

Six catégories de documents de Steering encodent désormais les normes organisationnelles de Rehrig Pacific dans chaque sortie générée par l'IA : pratiques de programmation, modèles d'infrastructure AWS, conception d'API, architecture de données, cadriciels et déploiement. Ces documents servent de contexte d'exploitation qui aide à garantir que la sortie de Kiro respecte les normes de Rehrig sans obliger les ingénieurs à expliquer les conventions à chaque requête.

Le travail de production passe par le processus des Specs afin d'obtenir de bons résultats, évolutifs. Kiro a fourni à Rehrig Pacific l'approche structurée et réfléchie que sa culture d'ingénierie exige.

Rehrig One : la démonstration

Le véritable test est venu avec Rehrig One, la priorité technologique numéro un de l'entreprise : une plateforme unifiée réunissant ses représentants commerciaux, automatisant le processus quote-to-cash et donnant aux clients un accès en libre-service à leurs données. Chaque évaluation antérieure de solutions prêtes à l'emploi était revenue avec le même constat : 60 % de ce dont ils avaient besoin. Pas assez proche pour justifier l'investissement, mais trop coûteux à construire à partir de zéro avec une petite équipe.

Rehrig One représentait deux initiatives distinctes dont la portée avait été évaluée indépendamment comme s'étendant sur plusieurs années. La première visait le processus quote-to-cash de l'arrière-guichet, en systématisant et en automatisant les transferts critiques entre les ventes et le traitement des commandes. La seconde était une plateforme d'expérience client pour l'accès aux données en libre-service et les interactions de soutien. Ensemble, le plan initial prévoyait de deux à trois ans de développement par étapes pour arriver à un prototype fonctionnel.

En janvier 2026, Rehrig Pacific a réuni 30 développeurs pour explorer un certain nombre de cas d'utilisation, dont un MVP pour Rehrig One, avec Kiro. Ces développeurs ont livré huit résultats prêts pour la production en 48 heures, un travail que l'entreprise estimait avoir exigé de cinq à huit sprints selon son processus antérieur.

Les dirigeants qui débattaient entre construire et acheter avaient leur réponse.

À la fin du mois de mai, Rehrig Pacific avait livré le premier de 6 modules d'un MVP fonctionnel qui dépassait la portée du plan de prototype initial. Le prototype qui devait prendre trois ans à atteindre était entre les mains des utilisateurs en moins de deux mois. Brian Rowe, vice-président de la technologie chez Rehrig, l'a dit simplement : l'équipe a livré en sept semaines un travail qui devait prendre environ trois ans, avec un seul développeur, et elle travaillait déjà à étendre l'incidence et la vélocité au reste de ses ressources.

Comment le travail a changé

Le changement vécu par l'équipe de Rehrig Pacific ne portait pas simplement sur la vitesse brute. Il portait sur l'endroit où va leur attention.

Avant d'adopter la méthodologie de développement native pour l'IA, l'équipe travaillait selon des méthodes Agile traditionnelles axées sur les sprints. Les propriétaires de produit définissaient et affinaient les récits utilisateur. Les cérémonies de sprint consommaient un temps de coordination important. Une équipe de développement de trois personnes passait de l'idée à la création de valeur sur plusieurs mois, structurellement limitée par le nombre de bras disponibles.

Aujourd'hui, les développeurs consacrent la majorité de leur temps à l'architecture, à la conception de systèmes et à l'affinage des requêtes. Ils accompagnent Kiro dans les cas limites, dépannent les endroits où le code généré doit être ajusté et contribuent à une bibliothèque grandissante de documents de Steering qui s'améliorent au fil du temps grâce à la collaboration entre pairs. Le travail mécanique (code standard, échafaudage de tests, modèles de mise en œuvre répétitifs) a été largement automatisé.

Le changement s'est étendu au-delà de l'équipe d'ingénierie. Le personnel non technique a trouvé un rôle productif en amont du processus : capter la réflexion produit non structurée, la transmettre à Kiro et laisser l'outil la structurer et l'affiner en exigences exploitables. Les gestionnaires de produit ont commencé à utiliser l'intégration Figma de Kiro pour du prototypage rapide, dépassant les maquettes esthétiques pour créer des prototypes interactifs qui définissent les exigences avec suffisamment de précision pour revenir à Kiro en vue d'une passe de spécification affinée.

L'équipe a créé 84 fichiers de specs pour gérer le MVP de Rehrig One, en remplacement des tickets Jira qui régissaient ses flux de travail antérieurs. Certains développeurs ont trouvé cela plus rapide que de passer par les tickets, et l'équipe a commencé à évaluer si les dépôts pouvaient contenir tout ce dont elle a besoin sans couche distincte de gestion de projet.

Au-delà du projet phare

Ce qui rend l'adoption par Rehrig Pacific remarquable, ce n'est pas l'initiative phare à elle seule. C'est l'ampleur. Au cours des mêmes sept semaines où Rehrig One est passé du concept au MVP en production, l'équipe a lancé des initiatives parallèles dans chaque partie de l'organisation. Par exemple, l'équipe a créé un système de gestion du rendement qui relie la stratégie de l'entreprise au travail de première ligne, une plateforme de visibilité TI/SecOps pour éliminer des heures de collecte manuelle de métriques, et une plateforme d'automatisation fondée sur des API qui permet aux ingénieurs de créer des automatisations protégées pour les équipes de soutien de niveau inférieur. Chacune a commencé avec Kiro et a progressé plus vite que quiconque l'avait cru possible.

Des projets qui étaient inconcevables il y a dix-huit mois (trop vastes, trop complexes, trop exigeants en ressources pour une petite équipe des TI) sont maintenant des éléments courants de la feuille de route. L'ancienne contrainte du manque de développeurs pour créer tout ce dont l'entreprise a besoin ne revient tout simplement plus. L'équipe ne se sent plus obligée de se contenter de moins. Elle peut offrir exactement l'expérience qu'elle souhaite : celle qui soutient le mieux sa marque, ses employés et ses clients.

Construire à la vitesse de l'ambition

Avancer à ce rythme a fait émerger un tout nouvel ensemble de défis. Ce sont le genre de défis qui n'existent que parce que l'équipe fonctionne maintenant à une échelle et à une vitesse qui étaient auparavant hors de portée.

L'équipe fait activement évoluer l'ensemble de son infrastructure de livraison : processus DevSecOps, approches d'assurance qualité et pratiques de revue de sécurité conçues pour la vélocité qu'elle soutient désormais. Ce travail s'étend aux normes fondamentales d'ingénierie, aux stratégies de branches, aux directives sur les pull requests et aux attentes en matière de revue de code. Les normes qui servaient une équipe de trois personnes sont reconstruites pour une équipe de 35 personnes fonctionnant à pleine vélocité.

« Nous avons rapidement constaté que nous devrions repenser l'ensemble de notre processus de livraison, a dit M. Rowe. Mais ce que nous construisons au passage, c'est une équipe de direction beaucoup plus agile, qui s'habitue à repérer rapidement ces incidences de deuxième et de troisième ordre, et à agir sur elles. »

La méthodologie de développement native pour l'IA couvre actuellement environ 50 % des projets de développement actifs de Rehrig Pacific. L'équipe a une visibilité claire sur la migration de l'ensemble du développement actif vers ce cadre dans un délai de trois à quatre mois. Elle travaille aussi activement à moderniser toutes les applications héritées avec Kiro, en appliquant la même approche axée sur les specs aux scénarios brownfield afin d'établir une compréhension fondamentale pour le nouveau développement.

Rehrig Pacific est passée de débattre de la faisabilité à choisir quoi construire ensuite — continuant de déplacer des marchandises, des ressources et des idées pour le compte de ses clients et de ses communautés, en livrant de la valeur client à la vitesse de l'IA.