Teri LeBlanc, Directrice technologique et cofondatrice de Drop – Série d’interviews

Même si le marché du cannabis à usage adulte du Colorado est opérationnel depuis plus d’une décennie, l’industrie du cannabis de l’État et ses clients peinent encore à trouver des services de livraison fiables qui respectent pleinement les réglementations strictes de l’État. Face à ces exigences importantes, les services de livraison peinent souvent à garantir que chaque étape de la transaction soit réalisée conformément. De plus, chaque État – et souvent chaque comté – applique des lois différentes concernant la livraison de cannabis, rendant la conformité loin d’être simple.

Alors que le Colorado a créé des licences de transporteur spécifiquement pour les candidats à l’équité sociale et les entrepreneurs, de nombreuses entreprises de transport manquent encore de partenariats stables ou de volumes de livraison substantiels, même sur un marché aussi robuste que celui du Colorado.

Pour examiner plus en profondeur la technologie qui simplifie le processus de livraison tout en reliant les services de transport détenus par des entreprises d’équité sociale à une clientèle plus importante, myCannabis.com a interviewé Teri LeBlanc, Directrice technologique et cofondatrice de Drop.

Quels ont été les cours les plus intéressants ou les plus utiles que vous avez suivis dans le cadre du programme d’informatique à l’Université de Louisiana‑Lafayette ?

Mon cours préféré était Systèmes d’exploitation, enseigné par l’un de mes professeurs favoris, le Dr Ashok Kumar. C’était le cours qui montrait comment le logiciel est réellement construit au-dessus du matériel. Nous avons commencé au niveau de la façon dont la machine interprète le courant électrique, avons progressé à travers le binaire et les jeux d’instructions, et à la fin nous avions personnalisé à la main un système d’exploitation complet.

Ce cours a changé ma façon de penser le logiciel. Une fois que vous avez vu l’ensemble de la pile, du courant dans un fil jusqu’à un programme en cours d’exécution, vous cessez de considérer chaque couche comme magique.

J’ai continué à créer des systèmes d’exploitation tout au long de ma carrière, des systèmes d’exploitation pour robots aux systèmes d’exploitation quantiques, et maintenant le système d’exploitation pour la livraison de cannabis.

En outre, comment le stage à l’université a-t-il renforcé votre compréhension des sujets très pertinents que vous avez étudiés ? En quoi le cadre universitaire vous a-t-il permis d’étudier ces sujets de façon beaucoup plus détaillée ?

Le cadre universitaire nous a donné la liberté de construire le robot que nous voulions, ce qui n’est pas le cas dans l’industrie, où le produit est généralement défini avant votre arrivée. J’ai choisi un robot autonome sous‑marin parce que je voulais travailler davantage avec le matériel et le logiciel et que je désirais vraiment travailler sur des projets spatiaux. L’environnement sous‑marin était le plus proche que je pouvais obtenir. Cette analogie est réelle, et c’est pourquoi la NASA entraîne les astronautes sous l’eau. Flottabilité neutre, pression, absence de GPS et impossibilité d’accéder à votre matériel une fois qu’il est déployé.

La recherche a donné lieu à une publication IEEE. Mais ce dont je me souviens le plus, c’est le premier test. Nous l’avons réalisé dans la piscine de mon oncle. Tout se passait bien, le robot nageait, puis il s’est arrêté. Nous l’avons sorti, ouvert le boîtier, et l’ordinateur à l’intérieur était en feu. Nous avions gravement sous‑estimé la quantité de refroidissement nécessaire dans une enceinte hermétique. Rien dans la conception n’était erroné sur le papier. Nous n’avions simplement pas prévu ce qui se passe lorsqu’on enferme un ordinateur dans une boîte sans issue pour la chaleur et qu’on le submerge. Nous sommes donc retournés à la planche à dessin et avons conçu correctement le système de refroidissement.

Lorsque vous créez un logiciel pour du matériel, vous ne savez pas vraiment si votre logiciel fonctionne tant que vous ne l’avez pas exécuté sur le matériel. Les projets purement logiciels n’ont pas cette complexité, et j’ai apprécié ce défi supplémentaire. En fin de compte, ce projet a orienté ma carrière. Je suis tombée amoureuse de la robotique, et mon premier emploi après l’université était ingénieure en robotique. Je ne suis toujours pas allée dans l’espace cependant. Peut‑être l’espace après le cannabis.

Quels types de produits avez‑vous supervisés en tant que responsable du développement logiciel chez Amazon ? Quelles ont été les choses les plus fascinantes que vous avez observées au sein du département Robotique ?

Mon premier poste chez Amazon consistait à diriger l’équipe d’ingénierie responsable de l’infrastructure logicielle qui connecte les appareils Alexa en ligne. Cela englobait la communication directe entre les appareils à la maison ainsi que la communication avec le cloud Amazon pour les services en ligne. C’est là que j’ai appris la notion d’échelle. Ce qu’il faut réellement pour déployer une technologie à l’échelle mondiale.

Mon deuxième poste était de diriger une équipe de roboticiens construisant des robots d’entrepôt entièrement autonomes. Celui‑ci était fascinant car il avait un caractère beaucoup plus recherche‑développement. Nous avions un bâtiment de bureaux rempli de parcours d’obstacles, et nous faisions passer les robots chaque nuit pour les tester. Nous testions également dans de vrais entrepôts, avec de véritables colis de clients.

La partie la plus intéressante de l’intégration de robots autonomes dans un espace où des personnes se déplacent également réside dans la recherche sur la façon dont les humains évoluent autour des robots. Nous avions des scientifiques en interne qui nous ont aidés à définir l’interface et les comportements d’interaction homme‑robot. En réalité, ce travail portait sur le comportement humain face à la technologie. Il s’est avéré directement utile depuis lors pour créer des applications que les gens souhaitent réellement utiliser.

Qu’est-ce qui a attiré votre attention professionnelle dans la conception d’une plateforme dédiée aux ventes de cannabis au détail et aux dispensaires ? Avez‑vous eu des inquiétudes ou des appréhensions au départ concernant la conception d’une plateforme pour l’industrie du cannabis ?

Mon amie et désormais co‑fondatrice de Drop, Kat Savoy, m’a proposé l’idée. Nous sommes toutes deux de ferventes connaisseuses de cannabis et passionnées de commodité. Elle m’a présenté ses recherches sur les besoins de l’industrie pour résoudre la livraison, et au moment où elle a fini de décrire le problème, j’avais déjà l’architecture du système en tête. J’ai su que je pouvais créer une plateforme qui servirait chaque utilisateur tout au long du cycle de vie d’une livraison de cannabis.

Mes préoccupations n’ont jamais porté sur le cannabis. Elles concernaient les contraintes. Vous ne pouvez pas utiliser les voies de paiement classiques. Chaque étape d’une livraison doit être vérifiable par un régulateur. Et une plateforme comme la nôtre ne peut pas détenir de licence, ce qui signifie que l’ensemble du produit doit fonctionner via des partenaires plutôt que de les contourner. Voilà les véritables problèmes de conception, et honnêtement, ce sont eux qui ont rendu le projet intéressant.

Le cannabis a une importance personnelle pour moi depuis longtemps et je suis reconnaissant de pouvoir continuer à développer des technologies dans des secteurs qui me passionnent.

Comment avez‑vous mobilisé votre vaste expérience en ingénierie logicielle chez Amazon et IonQ lors de la conception de l’interface qui est devenue Drop ? Quels concepts et stratégies logicielles efficaces de ces entreprises ont inspiré Drop ?

Ma carrière entière s’est déroulée sur des systèmes complexes où les composants distincts communiquent entre eux via des interfaces bien définies. J’ai conçu l’architecture de Drop de façon très similaire à la façon dont j’ai construit le système d’exploitation quantique pour les ordinateurs quantiques d’IonQ. Domaine complètement différent, même problème sous‑jacent. Une couche de contrôle détient l’état réel d’un système compliqué, et tout le reste fonctionne à travers elle plutôt qu’autour d’elle.

En pratique, cela signifie une API unique à laquelle chaque application de la plateforme se connecte. Le consommateur a sa propre application, le livreur en a une, le dispensaire en a une, mais toutes communiquent avec un même cerveau. L’orchestrateur est la seule entité qui comprend l’état complet du système, ce qui lui permet de diriger chaque utilisateur à travers chaque application. Chaque utilisateur ne voit que sa propre partie. Cela garde l’ensemble propre et traçable pour tous les acteurs.

Chez Amazon Robotics, le même schéma était appliqué. Nous gérions des flottes d’unités autonomes depuis un système central qui détenait la vue d’ensemble, tandis que chaque robot ne connaissait que sa propre tâche. Le dispatch de Drop fonctionne de la même façon, les livreurs remplaçant les robots. L’orchestrateur connaît chaque commande, chaque livreur et chaque dispensaire. Le livreur ne voit que son prochain arrêt.

Pourquoi pensez‑vous que le Colorado est un marché étatique idéal pour lancer la plateforme Drop ? Quels problèmes de l’industrie du Colorado la plateforme Drop est‑elle conçue pour résoudre ?

Le Colorado est l’un des États pionniers du cannabis et continue de faire progresser l’industrie. Il possède également un cadre réglementaire mature, ce qui compte plus qu’on ne le pense. Lorsque les règles sont claires et établies, on peut construire un système de conformité qui s’y aligne. C’est bien plus difficile dans un marché où les règles évoluent constamment.

Le Colorado a une réelle demande de livraison, mais l’infrastructure n’a jamais été mise en place. La livraison ici passe par des transporteurs agréés plutôt que par les dispensaires eux‑mêmes, et à Denver les magasins sont obligés d’utiliser un transporteur contractuel plutôt que de livrer eux‑mêmes. Ainsi, un dispensaire qui veut offrir la livraison doit trouver un transporteur, se coordonner avec lui et maintenir une traçabilité de conformité qui s’étend sur deux entreprises distinctement licenciées. La plupart de ces processus se font encore sur papier.

De plus, la livraison est autorisée municipalité par municipalité, et la plupart du Colorado l’interdit encore. La carte des zones desservables n’est pas un état, mais un patchwork qui évolue au fur et à mesure que les villes adhèrent.

C’est cet écart que Drop a été créé pour combler. Nous mettons en relation le dispensaire et le transporteur agréé, assurons la traçabilité de conformité entre eux et prenons en charge les parties que ni l’un ni l’autre ne souhaitent gérer : le dispatch, la vérification d’identité, les formalités étatiques et le paiement. La demande était déjà présente. L’infrastructure ne l’était pas.

Comment Drop offrira‑t‑il des opportunités commerciales supplémentaires et une visibilité de marque aux entreprises de transport et aux marques de cannabis détenues par des acteurs de l’équité sociale ? Comment la plateforme résoudra‑t‑elle les problèmes répandus auxquels ces entreprises sont confrontées ?

Le Colorado a réservé la livraison aux titulaires de licences d’équité sociale. Les permis de transporteur‑livreur ont d’abord été attribués aux opérateurs d’équité sociale, l’État a exonéré ces candidats des frais de licence, et Denver a décidé de rendre cette exclusivité permanente. Les transporteurs de livraison agréés à Denver sont des entreprises d’équité sociale. Elles ne sont pas un groupe que nous servons en marge ; elles constituent le côté transporteur de notre plateforme, et chaque commande qui transite par Drop génère des revenus pour l’une d’elles. Notre croissance et la leur sont donc identiques.

Le problème le plus difficile est ce qui se passe après qu’une personne obtient une licence. La licence est la partie que l’État aide à obtenir. Elle n’est pas fournie avec un logiciel d’expédition, un système de conformité, des relations avec les dispensaires ou des clients. Un transporteur nouvellement licencié disposant de deux véhicules se retrouve en concurrence avec l’infrastructure opérationnelle de sociétés bien plus grandes, et construire cette infrastructure est la partie coûteuse. La plupart d’entre eux ne peuvent pas se le permettre, et je soutiendrais qu’aucun ne devrait avoir à le faire.

C’est ce que la plateforme leur fournit dès le premier jour, sans aucun investissement en capital. Elle leur apporte également la demande, qui est la moitié la plus difficile. Un transporteur sur Drop est connecté à chaque dispensaire de la plateforme au lieu de devoir gagner chaque relation individuellement.

Pour les marques, le marché représente une nouvelle étagère. Un produit qui devait auparavant être trouvé par quelqu’un se rendant physiquement dans un magasin particulier est désormais visible par quiconque consulte le menu de ce magasin depuis chez soi. Les marques petites et nouvelles en tirent davantage profit que les marques établies, car la découverte est ce qui leur manque.

Du point de vue de l’ingénierie logicielle, comment l’application est‑elle conçue pour prendre en compte les règles actuelles et les éventuelles modifications des réglementations de transport du Colorado ?

Nous avons ajouté un moteur de règles pour les réglementations, car dans cette industrie il n’existe pas un jeu unique de règles applicable partout. Elles varient selon les juridictions et évoluent.

Le moteur les résout en chaîne. Une adresse de livraison se traduit en code postal, le code postal se traduit en municipalité qui la régit, et les règles applicables à cette commande proviennent de cette municipalité plutôt que d’une hypothèse unique à l’échelle de l’État intégrée dans le code. Que la livraison soit autorisée ou non, quelle est la fenêtre de livraison locale, et si les magasins peuvent livrer eux‑mêmes ou doivent recourir à un transporteur agréé. Deux clients à quelques pâtés de maisons l’un de l’autre peuvent être soumis à des règles différentes, et le moteur fait de cela une simple recherche plutôt qu’un cas spécial.

Ces règles résident dans la base de données plutôt que dans le code, avec l’enregistrement de la date à laquelle chaque municipalité a opté pour la livraison et qui a effectué la modification. Le vote d’une ville pour autoriser la livraison constitue une mise à jour de données, pas une version logicielle.

Autour du moteur, la conformité constitue sa propre couche plutôt que d’être dispersée dans le flux de commande. Les limites d’achat, l’éligibilité d’une adresse, la vérification d’identité et le suivi‑traçabilité existent chacun comme composants séparés. Chaque réglementation que nous appliquons possède un identifiant dans un registre interne, et le code qui l’applique cite directement cet identifiant ; ainsi, lorsqu’une règle change, retrouver chaque ligne concernée devient une recherche plutôt qu’une excavation.

Comment les réglementations de transport et de vente au détail dans d’autres marchés étatiques seront‑elles intégrées à la conception de Drop lors de l’expansion vers d’autres États ?

La plateforme a été conçue dès le départ pour cela. Chaque marché légal de livraison possède le même squelette : un système d’enregistrement d’État, un manifeste existant avant le déplacement du produit, la vérification d’âge à la porte, le produit non livré réconcilié, les qualifications du conducteur valides au moment de l’expédition. Ce squelette ne change pas lorsque nous franchissons une frontière d’État.

Ce qui change, ce sont les détails. Les plafonds d’achat, les heures de livraison, qui est autorisé à transporter, si une municipalité doit d’abord se prononcer. Ce sont les éléments que nous avons conçus pour être configurables plutôt que codés en dur. Ajouter un État consiste à enseigner au moteur les règles de cet État. Le produit sous‑jacent reste le même.

Le suivi‑traçabilité est l’intégration qui varie le plus d’un État à l’autre, c’est pourquoi elle est placée derrière sa propre frontière. La majorité des États utilisent METRC, et nous sommes un partenaire fournisseur intégré avec ce système, de sorte que l’arrière‑plan de conformité se propage directement. Un État utilisant un système différent devient simplement un nouvel adaptateur derrière la même interface, et non une nouvelle plateforme.

Le côté vente au détail se généralise de la même façon. Les dispensaires se connectent via leur système de point de vente, et les principales plateformes POS de cannabis opèrent dans de nombreux États, de sorte qu’une intégration construite au Colorado est largement la même intégration dans le marché suivant.

En tant que professionnel très expérimenté en conception et ingénierie logicielle, comment envisagez‑vous l’évolution et l’adaptation de cette technologie à mesure que l’industrie du cannabis elle‑même évolue ?

Une partie de ce qui rend ce produit difficile aujourd’hui disparaîtra simplement. Si le cannabis est reclassé ou légalisé au niveau fédéral, les contraintes bancaires s’assoupliront et le paiement ne sera plus une solution sur‑mesure. Le commerce interétatique deviendra possible, ce qui transformera la notion même de livraison. Une grande partie de la machinerie que nous avons construite spécifiquement pour contourner l’interdiction fédérale deviendra superflue. Je serais heureux de la supprimer.

Ce qui ne disparaîtra pas, c’est exactement ce autour duquel nous avons bâti la plateforme. La vérification d’âge à la porte ne disparaît pas avec la légalisation. L’alcool est légal depuis quatre‑vingt‑dix ans et on vous demande toujours une pièce d’identité. La chaîne de garde‑meuble ne disparaît pas. Prouver à un régulateur ce qui s’est passé, quand et à qui, ne disparaît pas. Ces exigences survivent à l’interdiction.

Les éléments qui restent stables à travers chaque version de cette industrie appartiennent au cœur du système. Les éléments qui sont volatils, et dans le cannabis c’est la majeure partie du règlement, appartiennent à la configuration où ils peuvent changer sans toucher au produit. Le changement réglementaire devient alors de la maintenance plutôt qu’une réécriture. 

Donc mon attente est que la surface de conformité devienne plus simple à certains endroits et plus exigeante à d’autres, et que le rôle de la plateforme reste le même. Conserver l’état réel du système, prouver chaque étape, et empêcher les opérateurs qui l’utilisent d’avoir à y penser. 

À plus long terme, le vrai produit est l’infrastructure plutôt qu’une application. Ce que nous avons réellement construit, c’est la capacité de transférer un produit réglementé d’un vendeur agréé à un acheteur vérifié, de prouver l’ensemble de la chaîne et de régler le paiement. 

Merci de nous avoir rejoints, Teri ! Pour plus d’informations sur Drop, veuillez visiter son site web.