Apple renforce son engagement envers l'intelligence artificielle en acquérant DarwinAI

Quand Apple a racheté DarwinAI, une petite société canadienne, la nouvelle est passée pour une ligne de plus dans une longue liste d'acquisitions. Elle disait pourtant quelque chose de précis. DarwinAI travaillait sur la réduction de taille des réseaux de neurones : rendre un modèle plus petit et plus rapide sans trop dégrader ce qu'il sait faire. Une entreprise qui achète cette compétence ne prépare pas un service en ligne. Elle prépare du calcul sur l'appareil.

C'est la ligne de partage qui structure tout le sujet de l'IA chez les fabricants de téléphones et d'ordinateurs. Un modèle peut tourner dans un centre de données, sur des machines qui coûtent des dizaines de milliers d'euros et consomment autant qu'un radiateur, ou dans la poche de l'utilisateur, sur une puce alimentée par une batterie et refroidie par rien du tout. Les deux options ne donnent ni les mêmes résultats, ni les mêmes garanties.

La mémoire décide avant la puissance

On parle beaucoup de puissance de calcul, et c'est rarement le facteur limitant sur un appareil mobile. La contrainte qui tranche, c'est la mémoire vive. Un modèle de langage doit tenir en mémoire pendant qu'il travaille, en entier, avec en plus l'espace de travail nécessaire au traitement du contexte.

Un calcul simple donne l'ordre de grandeur. Un modèle de sept milliards de paramètres stockés en seize bits occupe environ quatorze gigaoctets. Aucun téléphone ne peut se le permettre, puisque le système et les applications réclament déjà leur part. Réduit à huit bits, il descend vers sept gigaoctets, ce qui reste trop. Ramené à quatre bits, il approche des trois gigaoctets et demi, et là seulement la discussion devient possible sur un appareil haut de gamme. Voilà pourquoi les modèles pensés pour tourner en local se comptent en centaines de millions ou en quelques milliards de paramètres, jamais en centaines de milliards.

Compresser un modèle, et ce que ça enlève

Les techniques de réduction portent des noms différents mais visent la même chose. La quantification abaisse la précision numérique des poids. L'élagage supprime les connexions qui contribuent peu. La distillation entraîne un petit modèle à imiter les sorties d'un grand. Chacune fait gagner de la place et du temps de calcul, et chacune coûte quelque chose.

Ce coût n'est pas uniforme, et c'est ce qui rend ces modèles trompeurs à l'usage. Un modèle compressé reste très bon pour reformuler une phrase, résumer un message court, classer une photo, corriger une transcription vocale. Il décroche sur les tâches longues : suivre une consigne en plusieurs parties, tenir un raisonnement, retenir un contexte étendu sans se contredire. L'utilisateur qui teste avec des demandes simples trouve le résultat très correct, puis se heurte à un mur dès qu'il pousse un peu.

À cela s'ajoute une contrainte physique que les démonstrations ne montrent jamais : la chaleur. Faire tourner une puce d'accélération à plein régime pendant trente secondes sur un téléphone déclenche une réduction automatique de la fréquence. Le premier essai est rapide, le cinquième l'est moins. Sur batterie, l'écart est encore plus marqué.

La vie privée, argument commercial et réalité technique

Le traitement local a un avantage qu'aucune promesse contractuelle n'égale : ce qui ne quitte pas l'appareil ne peut être ni intercepté, ni conservé, ni réquisitionné. Les données les plus sensibles d'un téléphone sont exactement celles que l'IA a envie de lire : les messages, l'agenda, les photos, l'historique de localisation, la santé. Analyser tout cela en local change la nature du risque.

Il faut rester lucide sur la portée de l'argument. Local ne signifie pas hors de portée : une application locale peut très bien transmettre ses résultats ailleurs, et le chiffrement des sauvegardes reste un sujet distinct. La formule qui compte, dans une politique de confidentialité, n'est pas « le traitement a lieu sur votre appareil », mais l'énumération de ce qui est envoyé, à qui, et pour combien de temps c'est conservé.

Le compromis mis en avant par plusieurs fabricants consiste à envoyer les demandes lourdes vers des serveurs dédiés, en promettant que rien n'y est stocké et que le code exécuté est auditable. Techniquement, c'est un progrès réel par rapport à une interrogation de service en ligne classique. Ce n'est pas la même chose que le local, et il vaut mieux ne pas confondre les deux dans son esprit.

Le routage, la partie invisible et décisive

Un assistant qui mélange les trois niveaux doit décider, demande par demande, où envoyer le travail. Cette décision se prend en quelques millisecondes, sans que l'utilisateur en soit informé la plupart du temps. Elle dépend de la complexité estimée de la question, de l'état de la batterie, de la disponibilité du réseau, parfois du modèle d'appareil.

Cette logique de tri explique des comportements déroutants. La même question posée deux fois peut donner deux réponses de qualité différente, sans que rien n'ait changé du côté de l'utilisateur. En avion, avec le réseau coupé, l'assistant devient soudain plus limité. Sur un appareil de deux générations plus ancien, certaines fonctions ne s'affichent tout simplement pas, ce qui a nourri le soupçon d'obsolescence organisée alors que la mémoire vive suffit souvent à l'expliquer.

Ce que ça a changé pour le matériel

La conséquence la plus concrète de cette course n'est pas logicielle, elle est dans les caractéristiques des appareils. La quantité de mémoire vive est devenue le critère qui sépare les modèles capables d'exécuter les fonctions d'IA de ceux qui en sont écartés. Les puces embarquent des unités spécialisées dans le calcul matriciel, dont la bande passante mémoire compte davantage que la fréquence affichée.

Pour l'acheteur, la traduction pratique tient en deux points. Regarder la mémoire vive avant tout le reste, parce qu'elle ne s'ajoute pas après coup. Et se méfier des fonctions annoncées comme disponibles « sur les appareils compatibles », formule qui recouvre en général une liste plus courte que celle qu'on imagine.

Une acquisition qui disait où allait le vent

Rachetée pour son savoir-faire en compression de réseaux, DarwinAI vendait des systèmes d'inspection visuelle de composants, une application industrielle qui semblait à mille lieues d'un téléphone. Le lien tient à la méthode, pas au produit : détecter un défaut sur une chaîne de fabrication demande un modèle assez léger pour tourner sur place, assez rapide pour suivre la cadence, assez fiable pour ne pas rejeter des pièces bonnes. Les mêmes contraintes, à peu de chose près, que celles d'un assistant qui doit répondre en une seconde sans vider la batterie.

Le mouvement de fond de ces années-là s'est joué là, plus que dans les démonstrations de conversation. Rendre les modèles assez petits pour qu'ils descendent dans les appareils, quitte à leur retirer une partie de leurs capacités, plutôt que de tout renvoyer vers des serveurs. Le calcul est simple pour un fabricant de matériel : ce qui tourne en local ne coûte rien en fonctionnement, et donne un argument que les concurrents purement logiciels ne peuvent pas reprendre.