Être AI-native, ce n'est pas consommer plus de tokens — c'est repenser les workflows

Récemment, OpenAI a partagé les pratiques de trois entreprises AI-native : Basis, Clay et Exa.

Ces exemples ne consistent pas simplement à faire utiliser quelques outils d'IA de plus par les employés — ils consistent à placer des agents dans les workflows réels de l'entreprise :

Basis a transformé son processus d'onboarding des employés en Skills d'agents réutilisables ; Clay crée pour chaque client un espace de travail continuellement mis à jour et un agent dédié ; Exa, elle, laisse ses agents découvrir proactivement des opportunités d'intégration, rassembler des informations de contexte, écrire du code, lancer des tests, puis remettre les résultats aux humains pour revue.

Lien de l'article : OpenAI : How AI-native companies turn workflows into operating capability

Cet article m'a fait repenser ce que signifie vraiment être une entreprise AI-native.

Beaucoup d'entreprises utilisent l'IA aujourd'hui. Les employés s'en servent pour rédiger des e-mails, résumer des réunions, générer des textes ou répondre à des questions. L'entreprise consomme d'énormes quantités de tokens chaque mois, et tout cela a l'air très « IA ».

Mais si la façon de travailler de l'entreprise n'a pas changé, l'IA reste simplement un assistant plus pratique.

Utiliser beaucoup l'IA ne signifie pas qu'une entreprise est devenue AI-native.

Le vrai changement se produit dans le workflow lui-même.

Les logiciels traditionnels attendent généralement que l'humain fasse avancer le processus : l'employé se connecte, cherche la fonctionnalité, rassemble les documents, remplit le formulaire, puis transmet la tâche à la personne suivante.

Dans une manière de travailler AI-native, un agent peut observer l'état en continu, démarrer le travail proactivement quand les conditions déclenchantes apparaissent, appeler les outils dont il a besoin, conserver les preuves d'exécution — et rendre les décisions aux humains aux points critiques.

Le rôle de l'humain change en conséquence : d'une exécution répétée de chaque étape, il passe à la définition des objectifs, au traitement des exceptions et à la revue des résultats.

C'est aussi la direction que nous explorons en concevant SnapLedger et Snappy.

Par exemple, un logiciel de comptabilité traditionnel peut afficher un tableau de bord indiquant à l'utilisateur combien de transactions restent à traiter. Mais il exige toujours que l'utilisateur découvre lui-même le problème, le comprenne, puis cherche la fonctionnalité correspondante, élément par élément.

L'idée derrière Snappy of the Day est différente.

Snappy devrait combiner les transactions bancaires de l'utilisateur, ses documents, l'état de sa comptabilité, ses traces d'utilisation des outils et ses dates de conformité, pour juger ce que l'utilisateur a le plus besoin d'accomplir maintenant :

Y a-t-il aujourd'hui une transaction importante en attente de confirmation ? Y a-t-il une facture sans paiement correspondant ? La date de déclaration de TVA approche-t-elle ? Une tâche non terminée la dernière fois doit-elle être poursuivie ? Un nouvel outil pourrait-il aider l'utilisateur à résoudre le problème du moment ?

Il ne se contente pas de dire à l'utilisateur « voici une fonctionnalité » — il relie le contexte, les outils et la prochaine action.

De même, Snappy Front Desk ne devrait pas se contenter de générer un e-mail marketing. Il doit partir de la découverte d'un client potentiel, comprendre son contexte, choisir le bon canal de communication, enregistrer l'avancement de la conversation — et continuer à pousser l'inscription et l'adoption une fois que le client montre de l'intérêt.

Et quand un client formule une demande ou signale un bug, cela ne devrait pas rester une ligne dans un historique de chat. Les informations pertinentes peuvent être organisées en ticket, entrer dans le pipeline de développement et de test, et je révise périodiquement quelles modifications peuvent réellement être intégrées au produit.

Dans tous ces exemples, la valeur de l'IA ne réside pas dans la quantité de texte générée, mais dans sa capacité à mener un travail du début jusqu'au résultat.

Mesurer une entreprise AI-native ne devrait donc pas se limiter au volume d'appels de modèles ou à la consommation de tokens. Il faut poser des questions plus réelles :

• Combien de relais humains une tâche complète nécessite-t-elle ?
• Combien de contexte un agent peut-il conserver dans la durée ?
• Quelle part du travail passe du rappel à l'accomplissement ?
• Les exceptions sont-elles rendues aux humains à temps ?
• Les manières de travailler réussies peuvent-elles être sauvegardées et réutilisées ?
• Les gains d'efficacité se traduisent-ils finalement par des coûts plus bas, une livraison plus rapide ou un meilleur service ?

Je crois de plus en plus que l'écart en matière d'IA entre les entreprises de demain ne viendra pas simplement de qui utilise le modèle le plus puissant.

Le vrai écart tient à ceci : une entreprise sait-elle décomposer clairement son travail le plus important, fournir aux agents le bon contexte, les bons outils, les bonnes permissions et les bons critères d'achèvement — puis laisser les processus réussis se répéter et s'améliorer en continu.

Les modèles fournissent l'intelligence. Les workflows transforment l'intelligence en capacité.

Être AI-native, ce n'est pas que chacun utilise un peu plus l'IA — c'est que toute l'organisation accomplisse son travail d'une manière nouvelle.