Vibe Check : La checklist de sécurité du codeur intuitif

Si cela vaut la peine d'être construit, cela vaut la peine d'être sécurisé.

Le Vibe coding fait beaucoup parler de lui. Bien que l'automatisation et le codage avec l'IA ne soient pas nouveaux, le Vibe coding promet de démocratiser le développement logiciel : décrivez simplement ce que vous voulez en langage naturel et laissez le LLM faire le reste. 

Des IDE améliorés par l'IA comme Cursor, Copilot in VS Code, et Windsurf, aux plateformes qui abstraient complètement le codage (telles que Bolt, Lovable, et v0), il y a déjà eu une explosion d'outils dans cet espace, et nous nous attendons à ce que la croissance exponentielle se poursuive.

Consultez AINativeDev pour une vue d'ensemble du paysage du développement de l'IA  

Nous privilégions les interactions positives.

Il est libérateur de pouvoir construire rapidement et d'« oublier que le code existe même » – surtout si vous n'êtes pas un développeur professionnel – mais le plus grand risque avec le "vibe coding" est que vous ne savez pas ce que vous ne savez pas, et la plupart du temps, vous pourriez ne pas comprendre ce que fait le code généré par l'IA. 

Certes, vous pouvez valider qu'il fait ce que vous attendez de lui, mais sans savoir ce qui se passe sous le capot, vous ne saurez pas toujours quels risques le code crée avant qu'il ne soit trop tard (et le débogage est notoirement plus difficile que l'écriture du code en premier lieu). Si vous faites l'effort de construire quelque chose—même si vous accélérez ce processus par le vibe coding—la dernière chose que vous souhaitez est d'être freiné par des incidents de sécurité.

Même les développeurs expérimentés ont des angles morts en matière de sécurité, et bien que le « vibe coding » rende le développement logiciel plus accessible, il rend également plus rapide et plus facile d'exposer votre application à des vulnérabilités et des attaques, telles que les injections SQL, les attaques par traversée de chemin et les secrets vulnérables aux acteurs malveillants. Alors que certaines plateformes de « vibe coding » s'efforcent de prévenir les vulnérabilités (v0 est par défaut sceptique vis-à-vis du code LLM), il existe toujours un risque très réel de lacunes de sécurité lors du « vibe coding » — ce qui conduit à l'observation sarcastique que « vibe coding » = Vulnérabilité-en-tant-que-Service. 

Prenez simplement l'exemple ci-dessous :

‍

Malheureusement, il n'y a pas une raison évidente pour laquelle notre malheureux ami ci-dessus a dû fermer son application et tout recommencer. Il est clair que ses clés API ont été divulguées, ce qui a permis aux hackers de l'usurper, ce qui signifie qu'ils pouvaient accéder ou modifier des données, des fonctionnalités ou des ressources.

N'importe quel nombre de pièges liés à la gestion non sécurisée des clés API aurait pu être en jeu ici : le codage en dur de secrets dans son application, un fichier de variables d'environnement téléchargé involontairement sur son serveur, ou le fait d'être victime d'une vulnérabilité de traversée de chemin (hé, cela est même arrivé à Atlassian). Sans contrôles et processus de sécurité supplémentaires, il aurait été facile pour un hacker ou un bot d'accéder à ses clés API. 

Vulnérabilités et risques de sécurité courants

Que ce soit juste vous et ChatGPT, ou que vous codiez avec un outil dédié comme Lovable, vous êtes vulnérable à ces types courants de cyberattaques. 

cross-site scripting (XSS)

Une attaque par cross-site scripting (XSS) exploite les vulnérabilités des applications web où les entrées fournies par l'utilisateur ne sont pas correctement validées ou nettoyées avant d'être affichées ou traitées. Les hackers peuvent alors « injecter » du code malveillant via l'entrée utilisateur, et lorsque le script injecté est exécuté, il peut accéder à des informations sensibles ou effectuer des actions non autorisées au nom de la victime (dans ce cas, l'un de vos utilisateurs). Les attaques XSS peuvent être inoffensives (comme dans ce tweet auto-retweeté), mais elles exposent vos utilisateurs au risque de voir leurs données divulguées ou même leurs comptes pris en main par des hackers. 

Attaques par injection SQL

À l'instar des attaques XSS, une injection SQL (SQLi) injecte du code malveillant dans une application, souvent via un champ de saisie utilisateur vulnérable. Étant donné que SQL est le langage que de nombreuses applications utilisent pour interroger leur base de données sous-jacente, ce type d'attaque permet aux pirates de visualiser ou de modifier votre base de données, d'accéder à des données confidentielles ou même de supprimer des enregistrements. La fuite de données d'Equifax en 2017 a été le résultat d'une attaque par injection SQL ; Equifax elle-même n'était pas la cible directe, l'entreprise n'ayant pas appliqué un correctif de sécurité à l'une de ses dépendances.  

Attaques par Path Traversal

Les attaquants peuvent manipuler les entrées de chemin de fichier (généralement des URL ou des paramètres de fichier) pour tromper votre application afin qu'elle renvoie des fichiers ou des répertoires non publics, contournant ainsi les contrôles d'accès et leur permettant de lire et d'écrire dans des fichiers contenant des données confidentielles. Ce type d'attaque est également rendu possible par des entrées utilisateur non sécurisées. En 2010, des chercheurs ont découvert une vulnérabilité de traversée de chemin (path traversal) dans l'application Confluence d'Atlassian qui aurait permis aux attaquants de récupérer n'importe quel fichier sur le serveur exécutant Confluence, en fonction des permissions de l'utilisateur sous lequel Confluence était exécuté.

Fuite de secrets

Les secrets — tels que les mots de passe, les clés de chiffrement, les jetons API et les certificats numériques — donnent aux acteurs malveillants les clés de votre royaume. Ces données sensibles peuvent permettre aux hackers de vous usurper l'identité, d'accéder à vos données et de modifier votre code. Un nombre stupéfiant de 23 millions de secrets ont été découverts dans des dépôts de code source publics en 2024, selon le rapport State of Secrets Sprawl de GitGuardian (soit une augmentation de 25 % par rapport à l'année précédente). Les secrets peuvent être exposés en les codant accidentellement en dur dans votre application, ou via une vulnérabilité comme le compromis tj-actions/changed-files de mars 2025 : des attaquants ont modifié le code de l'action GitHub tj-actions/changed-files, ce qui a entraîné l'impression des secrets CI/CD dans les journaux de build de GitHub Actions par l'action compromise.

attaques de la chaîne d’approvisionnement

Jusqu'à 85 à 95 % du code de votre application pourrait être alimenté par des bibliothèques et des projets open source. Les attaques de la chaîne d'approvisionnement n'exploitent pas un type spécifique de vulnérabilité ni ne ciblent une application particulière, mais s'attaquent plutôt aux projets open source sous-jacents dont dépendent de nombreuses entreprises. La violation de données d'Equifax mentionnée ci-dessus était le résultat d'une attaque de la chaîne d'approvisionnement qui avait déjà été atténuée, ce qui démontre l'importance de surveiller vos dépendances et d'appliquer rapidement les correctifs de sécurité. 

Le Vibe coding est un outil formidable pour l'exploration et la création d'une preuve de concept, mais dès que vous souhaitez transformer quelque chose en un produit et une entreprise viables, vous voudrez mettre en place des contrôles de sécurité et des bonnes pratiques pour protéger ce que vous avez construit. 

Ne suffit-il pas de demander à l'IA de générer du code plus sécurisé ?

Écoutez, c'est une question légitime. Nous savons que l'IA n'écrit pas de code sécurisé par défaut, mais une amélioration très rapide et simple consiste à lui demander explicitement de le rendre sécurisé (en ajoutant littéralement les mots « et rendez-le sécurisé » à votre prompt). Étonnamment, cela conduit effectivement à un code avec moins de vulnérabilités.

Vous pouvez également demander à l'IA de réviser son propre code pour détecter les vulnérabilités et les lacunes de sécurité, par exemple en lui demandant de trouver les secrets codés en dur, de vérifier que les données ne sont pas accessibles publiquement, d'analyser le projet pour les dépendances vulnérables, ou d'identifier les champs de saisie utilisateur (tels que les formulaires) avec une validation d'entrée insuffisante. Tous ces efforts amélioreront la sécurité de votre application.

Mais l'intérêt de vérifier le code généré par l'IA pour détecter d'éventuelles hallucinations, vulnérabilités ou autres lacunes de sécurité est qu'il est trop risqué de le laisser se corriger sans supervision humaine. Vous pouvez absolument intégrer l'IA aux méthodes de scan traditionnelles pour améliorer les choses, mais pas les remplacer (par exemple, Aikido utilise l'IA pour le triage automatique des alertes de sécurité et la proposition de correctifs).

Les ingénieurs logiciels les plus compétents sont aussi généralement ceux qui sont le plus à l'aise pour admettre quand ils ne savent pas quelque chose. Le problème de trop s'appuyer sur l'IA pour s'auto-réguler est qu'il n'est pas rare qu'elle fasse une affirmation confiante sur quelque chose de faux, au lieu d'admettre l'incertitude. C'est pourquoi nous ne recommandons pas de se fier uniquement à l'IA pour sécuriser votre application.

La bonne nouvelle est que de nombreuses entreprises et projets open-source se sont consacrés à la résolution de ces problèmes de sécurité bien avant que le "vibe coding" ne devienne une réalité. L'une des plus grandes leçons que les nouveaux développeurs apprennent est de s'appuyer sur le travail des géants. Votre application comportera de nombreux composants sensibles et critiques (des éléments comme l'authentification, la cryptographie, ou même simplement la manière dont vous permettez aux utilisateurs de télécharger des fichiers sur votre interface utilisateur), et demander à Cursor ou GPT de les construire pour vous est : 

1. Ne contribuera pas à la différenciation de votre produit
2. Très susceptible d'introduire des risques de sécurité

Il est bien préférable dans ces cas de s'appuyer sur des fournisseurs qui se concentrent uniquement sur les solutions à ces problèmes. Les LLM ne sont pas spécifiquement entraînés sur les meilleures pratiques ou sur la résolution d'un problème de la manière la plus efficace ou la plus sécurisée. Dans de nombreux cas, la solution la plus élégante consiste à utiliser un service préexistant plutôt que de construire le vôtre (même si vous déléguez le gros du travail à l'IA).

Il est facile de se sentir dépassé et de ne pas savoir par où commencer. Nous avons élaboré cette checklist pour vous aider à commencer à construire de manière plus sécurisée. 

Niveau 0

Ce sont les mesures de sécurité essentielles que vous voudrez mettre en place dès que possible. Une fois ces pratiques établies et intégrées à votre processus, vous pourrez développer librement sans nuire à l'élan.

Mettre en œuvre les meilleures pratiques Git

L'un des pièges courants du « vibe coding » est que, lors de l'ajout de nouvelles fonctionnalités ou de la tentative de résolution d'un problème, il est plus intuitif de simplement remplacer ce que vous aviez auparavant par le nouveau code généré par l'IA. Cela fonctionne jusqu'à ce que ça ne fonctionne plus ; finalement, vous pourriez vous heurter à un mur où rien de ce que l'IA produit n'aide et vous êtes même dans une situation pire qu'auparavant.

C'est à cela que sert le contrôle de version.

Le contrôle de version, comme Git, est apparu comme un moyen pour les développeurs de collaborer sur des projets sans écraser le travail des autres. Mais même si vous développez seul, il sert à sauvegarder votre progression, ce qui aide à isoler les bugs et à pouvoir annuler une modification en cas de problème. Voici trois pratiques Git essentielles qui vous aideront à développer de manière plus sécurisée :

Créer un fichier .gitignore pour les fichiers sensibles

Un fichier .gitignore est un simple fichier texte brut qui indique à Git ce qu'il doit ignorer (c'est-à-dire ne pas commettre dans votre dépôt). Généralement, vous souhaitez que Git ignore les fichiers générés par ordinateur, tels que les logs, car ils encombrent votre dépôt et pourraient contenir des informations sur l'application susceptibles d'être utilisées pour la compromettre. Votre fichier .env doit également être ignoré, car il contient des variables d'environnement sensibles (comme les clés API et les mots de passe) que des hackers pourraient utiliser pour vous usurper et accéder à votre système. 

Maintenir un historique de commits clair

Maintenir les changements aussi autonomes que possible facilite l'identification du moment où un bug ou une vulnérabilité a été introduit, et simplifie la reversion sans avoir à refaire d'autres travaux. Aller plus loin en configurant des commits signés vérifie que les bons développeurs s'engagent à votre dépôt (même si ce n'est que vous !). 

Séparer les branches de développement de fonctionnalités, de staging et de production

Le branching dans Git permet de créer des espaces distincts et autonomes pour développer, prévisualiser et déployer du code. Le développement actif de nouvelles fonctionnalités dans une branche séparée permet d'éviter que du code incomplet, bogué ou non sécurisé ne soit accidentellement commité dans votre application en production. Une fois qu'une nouvelle fonctionnalité est entièrement développée et testée, une branche de staging agit comme une porte de sécurité et de qualité supplémentaire, vous permettant de réviser et de finaliser les modifications avant le déploiement en production. Seules les fonctionnalités entièrement testées et stables peuvent ensuite être fusionnées dans votre branche de production (généralement appelée main).

Dépôts Git hébergés : GitHub GitLab   

Séparer les secrets du code

‍

‍

Les secrets — tels que vos mots de passe, clés de chiffrement, jetons API et certificats numériques — doivent être gérés séparément du code pour éviter de les commettre directement dans votre base de code. Vous pouvez vérifier votre code à la recherche de secrets avec Aikido, même depuis votre IDE Cursor.

Protégez votre application contre les attaques DDoS

Une attaque par déni de service distribué (DDoS) tente de perturber le trafic normal d'un serveur, d'un service ou d'un réseau ciblé en submergeant la cible ou son infrastructure environnante avec un pic de trafic Internet. Ces attaques peuvent avoir des conséquences dévastatrices, et il est étonnamment simple de se protéger en intégrant des protections DDoS de base avec un réseau de diffusion de contenu (CDN) comme CloudFlare ou CloudFront. Certains fournisseurs d'hébergement de domaines proposent même un CDN comme service intégré. 

Ne gérez pas l'authentification vous-même

L'authentification (comme votre flux de connexion) est un composant sensible de votre application que vous voudrez confier à des experts. L'utilisation d'un outil dédié pour appliquer une politique de mots de passe et offrir facilement l'authentification unique (single sign-on) ou même l'authentification multi-facteurs pour votre application à mesure que vous montez en charge protégera vos comptes utilisateurs et votre réputation. 

Excellents outils : Auth0, Quasr 

N'implémentez jamais votre propre cryptographie

De même, la cryptographie est une expertise, reposez-vous toujours sur des mécanismes, des bibliothèques et des outils établis. Développer vos propres implémentations, ou utiliser des flags et des options que vous ne comprenez pas entièrement,

vous exposera à des risques majeurs. Des bibliothèques comme NaCL offrent peu d'options, vous limitant à de bons choix.

Niveau 1

Mettre en place un pipeline CI/CD pour surveiller votre code

La mise en œuvre d'un pipeline CI/CD avec des tests revient à ajouter des points de contrôle qualité à la chaîne d'assemblage du code de votre application. Vous pouvez intégrer des outils d'analyse statique du code pour effectuer des Tests de sécurité des applications statiques (SAST), qui scannent votre code à la recherche de failles pouvant entraîner des vulnérabilités de sécurité. Vous pouvez également intégrer un outil de Tests de sécurité des applications dynamiques (DAST, parfois appelé surveillance de surface) pour simuler des attaques et identifier les vulnérabilités dans le frontend de votre application web (comme la recherche de ports ouverts ou de trafic entrant non restreint). 

DAST open source : ZAP

SAST open source : Opengrep

Surveillez vos dépendances  

Que vous en soyez conscient ou non, la majeure partie du code qui alimente votre application provient probablement de projets open-source et de bibliothèques tierces sur lesquels les modèles d'IA sont entraînés. Ce sont vos dépendances, et parfois même celles-ci ont leurs propres dépendances, l'ensemble constituant votre chaîne d'approvisionnement logicielle. Une seule faille dans l'une de ces bibliothèques pourrait mettre en péril l'ensemble de votre application, mais vous pouvez réduire ce risque en utilisant les bons outils pour surveiller vos dépendances à la recherche de vulnérabilités connues.

Outil recommandé : Trivy

Configurez-le en quelques secondes avec Aikido

Vérifiez vos dépendances à la recherche de malwares

De même, votre chaîne d'approvisionnement peut inclure des packages malveillants contenant des malwares. Ceux-ci sont exceptionnellement dangereux, car les attaquants agissent généralement rapidement après avoir réussi à introduire des malwares dans votre code. Vous devez donc également réagir rapidement. Notez que les bases de données Common Vulnerabilities and Exposures (CVE) sont trop lentes et ne vous protégeront pas de ce type d'attaques.

Outils : Aikido Intel

Configurez-le en quelques secondes avec Aikido

Utiliser des lockfiles pour protéger votre chaîne d'approvisionnement

Si vous n'utilisez pas de fichiers de verrouillage (lockfiles), chaque fois que vous construisez votre application, vous récupérerez les dernières versions de tous les paquets open-source. Les fichiers de verrouillage permettent des builds reproductibles en utilisant les mêmes versions de vos dépendances open-source. Cela maintient la stabilité de votre application en cas de changements majeurs (breaking changes) dans vos dépendances, mais protège également votre application contre les attaques de la chaîne d'approvisionnement lorsque la dernière version d'une dépendance a été compromise. Un exemple récent est la vulnérabilité tj-actions/changed-files de mars 2025 : des attaquants ont modifié le code de l'action GitHub tj-actions/changed-files, ce qui a entraîné l'impression de secrets CI/CD dans les journaux de build de GitHub Actions par l'action compromise.

Prévenir les attaques XSS avec des en-têtes CSP stricts

Les en-têtes CSP peuvent vous protéger des attaques XSS courantes en fournissant une couche de sécurité supplémentaire qui contrôle les ressources dynamiques autorisées à se charger. Cela empêche les attaquants d'injecter des scripts dans vos pages web.

Vérifiez si vous les avez configurés correctement avec Aikido

Utilisez un pare-feu applicatif

Utilisez un pare-feu applicatif (WAF) ou l'autoprotection des applications en temps d'exécution (RASP) pour protéger les serveurs exposés au web contre les menaces zero-day inconnues, y compris les injections SQL ou les menaces XSS inconnues. L'outil scanne et prévient les requêtes utilisateur présentant un comportement suspect ou malveillant (tel qu'une charge utile d'injection), agissant comme une dernière ligne de défense contre les attaques. 

Excellents outils : AWS WAF Aikido Zen

Niveau 2

Avec les mesures de sécurité ci-dessus en place, il est temps d'améliorer votre posture de sécurité.

Mettre en œuvre les meilleures pratiques pour les conteneurs

Les conteneurs empaquettent les logiciels de manière à ce qu'ils puissent fonctionner de manière fiable lorsqu'ils sont déplacés d'un environnement informatique à un autre. Ils regroupent une application et toutes ses dépendances nécessaires, telles que les bibliothèques, les cadres et les fichiers de configuration (tout ce qui fait partie de votre chaîne d'approvisionnement), en un seul paquet. Cela garantit que l'application fonctionne de manière cohérente, quel que soit l'environnement dans lequel elle est déployée. 

Si vous utilisez des conteneurs pour le déploiement, il existe des bonnes pratiques qui vous aideront à renforcer la sécurité de votre application.

Maintenez vos images de base Docker à jour 

Les vulnérabilités dans votre image de base de conteneur (le modèle de composition de votre conteneur) mettent votre application en péril. Téléchargez régulièrement toutes les mises à jour de sécurité pour votre image de base. Pour les serveurs, vous pouvez déléguer cette tâche à un fournisseur PaaS comme Heroku ou AWS Beanstalk.

Scannez la sécurité de vos conteneurs Docker en utilisant : Syft Grype Trivy

Configurez-le en quelques secondes avec Aikido

Exécutez des conteneurs Docker avec des privilèges restreints

Des privilèges limités rendent difficile pour les attaquants de prendre le contrôle de l'hôte ou de rebondir vers d'autres services. Évitez d'exécuter des conteneurs avec des rôles d'utilisateur privilégiés, tels que root sur les systèmes Unix, ou Administrateur ou Système sur les systèmes Windows.

Protégez vos secrets.

Séparer les secrets du code est un excellent début. Si vous utilisez des conteneurs, vous voudrez également vous assurer que vos fichiers de secrets et autres données sensibles sont adéquatement protégés. Cela inclut l'utilisation d'outils de gestion des secrets (de nombreux fournisseurs cloud proposent les leurs), les secrets Kubernetes si vous utilisez Kubernetes, la rotation régulière des secrets et la définition de dates d'expiration pour vos secrets. 

Outils de gestion des secrets : HashiCorp Vault AWS Secrets Manager Google Cloud Secret Manager

En savoir plus : Gérer les secrets en toute sécurité dans les conteneurs : Bonnes pratiques et stratégies

Vérifiez la fin de vie (EOL) de vos packages

À mesure que les packages vieillissent et ne sont plus pris en charge, le risque d'exploits augmente. Vous devez vous assurer de mettre à niveau les packages qui atteindront bientôt leur fin de vie.

Ou configurez-le en quelques secondes avec la fonctionnalité de scan de conteneurs d'Aikido

Mettez en œuvre les meilleures pratiques pour vos comptes cloud

Maintenez des comptes cloud distincts pour le développement, la pré-production et la production 

De même que vous souhaitez séparer vos branches Git de développement, de staging et de production, il en va de même pour vos comptes cloud. Bien que vous puissiez créer des réseaux virtuels au sein de vos comptes cloud pour maintenir la séparation entre le staging et la production, cela peut devenir complexe à gérer à mesure que vous évoluez, car vous devrez continuellement gérer les droits d'accès des utilisateurs pour les nouveaux développeurs. Nous recommandons de maintenir les infrastructures de développement, de staging et de production dans des comptes cloud entièrement distincts. Tous les fournisseurs de cloud offrent une facturation unifiée, ce qui représente une préoccupation en moins.

Utilisez des outils de gestion de la posture de sécurité cloud

Les fournisseurs de cloud offrent tellement de fonctionnalités qu'il est facile de manquer ou de mal configurer quelque chose qui vous expose à des risques. Utilisez un outil de gestion de la posture de sécurité cloud (CSPM) pour analyser votre cloud à la recherche d'anomalies.

Outils CSPM : Cloudsploit AWS Inspector

Configurez-le en quelques secondes avec Aikido

Activez les alertes de budget cloud

Dans l'éventualité où votre compte cloud serait piraté, un moyen infaillible de détecter qu'une personne mine du Bitcoin sur votre compte est de configurer des alertes budgétaires pour surveiller les dépenses. Votre fournisseur de cloud devrait offrir des alertes intégrées à cet effet, ou vous pouvez configurer l'analyse cloud avec Aikido pour vérifier les problèmes budgétaires et les mauvaises configurations risquées. 

Vérifiez vos LLM à la recherche des exploits les plus courants

En plus de développer avec des LLM, vous pourriez intégrer des LLM dans votre produit destiné au public. Vous pourriez avoir un chatbot offrant un support aux utilisateurs, ou un assistant IA qui les aide à la prise en main. Si vos clients interagissent avec un LLM sous quelque forme que ce soit, il est judicieux de les tester pour les exploits les plus courants afin de ne pas les exposer à des risques de sécurité. 

Vérifiez les exploits les plus courants : Top 10 OWASP pour les LLM

Au-delà

Mettre en œuvre un cycle de vie de développement sécurisé

Une grande partie de la pratique de sécurité moderne consiste à opérer un shift-left, c'est-à-dire à intégrer les mesures de sécurité plus tôt dans le cycle de vie du développement. Cela vous aide à prendre l'habitude des bonnes pratiques à chaque étape du projet et à détecter les problèmes plus tôt avant qu'ils ne deviennent une réelle menace. Cela implique d'adhérer à une checklist de sécurité comme celle-ci, de vous familiariser avec les failles de sécurité typiques et de les rechercher pendant la code review, ainsi que de mettre en œuvre des contrôles de sécurité sur les pull requests. 

En savoir plus : OWASP Top Ten

En savoir plus : Article Wikipédia sur le cycle de vie du développement de systèmes

N'importe qui peut être victime d'une cyberattaque — même les entreprises multinationales dotées de départements de sécurité dédiés sont toujours vulnérables aux violations. Bien que le "vibe code" ne soit pas sécurisé par défaut, en adoptant les meilleures pratiques de sécurité dès le départ, vous pouvez toujours vous laisser porter par l'inspiration. Tout ce que vous construisez en vaut la peine. 

Lectures complémentaires

• Checklist de sécurité SaaS pour CTO 2025 d'Aikido
• Le guide open source de la sécurité des applications pour les startups

Téléchargez votre checklist de sécurité Vibe Coding gratuite