Comment choisir un partenaire tech en qui vous pouvez vraiment avoir confiance
Selon le Standish Group, 83,9 % des projets informatiques échouent partiellement ou totalement. Derrière ce chiffre se cache une réalité que connaissent trop de dirigeants et DSI : un prestataire mal choisi transforme un investissement stratégique en gouffre financier. Le BCG confirmait en 2024 que près de la moitié des entreprises interrogées déclaraient plus de 30 % de leurs projets tech affectés par des retards ou des dépassements budgétaires. Le problème n'est presque jamais la technologie elle-même. C'est la confiance mal placée dans un partenaire qui ne méritait pas cette confiance.
Cet article vous donne les clés concrètes pour identifier les signaux de sérieux, de transparence et de compétence réelle chez un prestataire de développement IA — et les red flags qui doivent vous faire fuir avant de signer.
TL;DR : Un partenaire tech fiable se reconnaît à sa transparence contractuelle, à la séniorité vérifiable de ses équipes, à sa capacité à dire non et à cadrer un périmètre. Cet article détaille 7 catégories de signaux forts et faibles, avec une checklist actionnable pour sécuriser votre choix.
Le coût réel d'un mauvais choix de prestataire
Un problème systémique, pas anecdotique
Le marché des ESN en France pèse 34,5 milliards d'euros en 2024 selon Numeum. Plus de 55 % des entreprises externalisent leur développement logiciel pour accéder à des compétences spécialisées (Gartner, 2024). Pourtant, le taux de réussite des projets IT plafonne autour de 29 à 31 % selon les éditions successives du CHAOS Report du Standish Group. L'écart entre le volume d'externalisation et le taux de succès révèle un dysfonctionnement structurel dans la manière dont les entreprises sélectionnent leurs partenaires.
Les chiffres sont parlants : 52,7 % des projets dépassent leurs prévisions budgétaires de 189 % en moyenne. Un projet informatique sur six se transforme en « cygne noir » — dépassement de coût de 200 %, dépassement de calendrier de 70 %. Pour une PME dont le budget IT annuel se situe entre 30 000 € et 150 000 €, un seul projet raté peut absorber l'intégralité de l'enveloppe technologique de l'année.
Pourquoi les ETI sont les plus vulnérables
Les Entreprises de Taille Intermédiaire présentent le taux d'abandon de projets le plus élevé. Elles disposent de suffisamment de ressources pour lancer des projets complexes, mais pas assez de maturité organisationnelle pour absorber les défaillances d'un prestataire. Contrairement aux grands groupes qui ont institutionnalisé leurs processus de sélection fournisseurs, les ETI s'appuient souvent sur des recommandations informelles ou sur l'impression laissée lors d'une présentation commerciale.
Le vrai coût d'un mauvais partenaire ne se limite pas au budget du projet. Il inclut le temps perdu par les équipes internes mobilisées pour compenser les défaillances, la dette technique héritée d'un code de mauvaise qualité, le retard sur le time-to-market face à des concurrents plus agiles, et la perte de confiance interne dans la capacité de l'entreprise à mener des projets technologiques.
Les 5 signaux forts d'un partenaire tech fiable
Signal 1 : La transparence sur les compétences réelles de l'équipe projet
Un prestataire sérieux vous présente nommément les développeurs qui travailleront sur votre projet, avec leurs parcours vérifiables. Le signal d'alerte inverse : on vous promet des « experts seniors » sans jamais vous laisser échanger avec eux avant la signature.
Selon Forrester, plus de 60 % des décideurs IT classent l'expérience d'implémentation au-dessus de la notoriété de la marque dans leurs critères de sélection. Ce chiffre traduit une prise de conscience : ce qui compte, c'est qui code réellement, pas le logo sur la proposition commerciale.
Posez ces questions concrètes : combien d'années d'expérience a le développeur principal affecté à mon projet ? Puis-je voir son profil LinkedIn ou GitHub ? Le prestataire sous-traite-t-il une partie du développement à des équipes offshore non déclarées ? Un partenaire fiable répond à ces questions sans hésiter.
Signal 2 : La capacité à dire non et à cadrer le périmètre
Un bon prestataire ne dit pas oui à tout. Quand vous décrivez votre besoin, il reformule, il challenge, il propose des arbitrages. Un prestataire qui acquiesce à chaque demande sans poser de questions est soit incompétent, soit en train de construire un devis qui explosera en phase de réalisation.
Le cadrage du périmètre est le moment de vérité. Un partenaire de confiance produit un document de spécifications fonctionnelles détaillé avant de chiffrer. Il identifie les zones de risque. Il explicite ce qui est inclus ET ce qui ne l'est pas. Il propose une approche itérative avec des jalons de validation plutôt qu'un « tunnel » de développement de six mois sans visibilité.
Signal 3 : Des références vérifiables et contextualisées
Les témoignages clients sur un site web ne valent rien s'ils ne sont pas vérifiables. Un prestataire fiable vous met en relation directe avec d'anciens clients, dans des contextes similaires au vôtre. La question à poser à ces références n'est pas « étiez-vous satisfait ? » mais plutôt : « Qu'est-ce qui s'est mal passé et comment le prestataire a-t-il géré la situation ? »
La gestion des problèmes est le vrai révélateur. Tous les projets rencontrent des difficultés. Ce qui distingue un bon partenaire, c'est sa réactivité face à l'imprévu, sa transparence sur les erreurs commises et sa capacité à proposer des solutions plutôt qu'à chercher des coupables.
Signal 4 : La clarté contractuelle et la réversibilité
En 2026, la majorité des nouveaux contrats dans le secteur intègrent des clauses de réversibilité et de transparence algorithmique. C'est un signal de maturité du marché — mais tous les prestataires n'ont pas suivi cette évolution.
Les red flags contractuels à repérer :
| Clause suspecte | Ce que ça signifie | Ce qu'il faut exiger |
|---|---|---|
| « Mesures de sécurité raisonnables » | Aucun engagement concret | SLA chiffrés avec pénalités |
| « Notification dans un délai raisonnable » | Aucune obligation de timing | Délai de notification précis (24h, 48h) |
| Pas de clause de sortie | Dépendance totale au prestataire | Plan de réversibilité documenté |
| Renouvellement automatique sans préavis clair | Verrouillage commercial | Fenêtre de résiliation de 90 jours minimum |
| Propriété intellectuelle floue | Le prestataire reste propriétaire du code | Cession complète du code source et de la documentation |
Un partenaire de confiance n'a aucun intérêt à vous verrouiller. Sa meilleure protection, c'est la qualité de son travail, pas une clause contractuelle piégeuse.
Signal 5 : Une méthodologie de travail explicite et vérifiable
Demandez au prestataire de vous décrire concrètement comment se déroule un projet chez lui. Pas les grands principes agiles affichés sur son site — le déroulement réel, semaine par semaine. À quelle fréquence recevrez-vous des livrables intermédiaires ? Quel outil de suivi sera utilisé ? Qui est votre interlocuteur unique ? Comment sont gérés les changements de périmètre ?
Un prestataire structuré vous fournit cette réponse spontanément, souvent dès la phase de proposition commerciale. Un prestataire désorganisé improvise sa réponse ou vous renvoie vers des termes génériques (« on fait de l'agile »).
Les 7 red flags qui doivent déclencher l'alerte
Red flag 1 : Le prix anormalement bas
Un devis 40 à 50 % en dessous de la moyenne du marché n'est pas une bonne affaire — c'est un risque majeur. Derrière un prix cassé se cache presque toujours l'un de ces scénarios : des développeurs juniors présentés comme seniors, une sous-traitance offshore non déclarée, un périmètre volontairement sous-évalué qui explosera en avenants, ou une absence totale de tests et de documentation.
Le marché français du développement IA a ses réalités économiques. Un développeur senior avec 10+ ans d'expérience coûte entre 500 € et 800 € HT par jour en régie. Si un prestataire vous propose un projet complexe à un tarif qui implique un TJM inférieur à 300 €, posez-vous la question de qui code réellement.
Red flag 2 : L'absence de questions sur votre métier
Un prestataire qui ne cherche pas à comprendre votre activité, vos utilisateurs et vos contraintes métier avant de proposer une solution technique construit dans le vide. La phase de découverte est le fondement d'un projet réussi. Si votre interlocuteur passe directement du brief initial à la proposition chiffrée sans phase intermédiaire d'exploration, c'est un signal d'alarme.
Un bon partenaire tech vous pose des questions parfois inconfortables : qui sont réellement vos utilisateurs finaux ? Avez-vous validé le besoin auprès d'eux ? Quelle est votre capacité d'adoption interne ? Ces questions ne sont pas de l'ingérence — elles sont la preuve que le prestataire s'investit dans la réussite du projet, pas seulement dans la facturation.
Red flag 3 : Les promesses technologiques sans nuances
« On va mettre de l'IA partout. » « Notre solution révolutionne le marché. » « Avec notre technologie, vous aurez un ROI de 300 % en six mois. » Ces formulations trahissent soit une incompétence (le prestataire ne comprend pas les limites de la technologie), soit une malhonnêteté commerciale (il sait que c'est faux mais veut closer).
Un partenaire compétent en IA vous explique ce que la technologie peut faire ET ce qu'elle ne peut pas faire dans votre contexte. Il parle de cas d'usage spécifiques, pas de promesses génériques. Il mentionne les prérequis (qualité des données, infrastructure, accompagnement au changement) plutôt que de laisser croire que la technologie résout tout par magie.
Red flag 4 : L'opacité sur la composition de l'équipe
65 % des entreprises françaises privilégient un prestataire français pour leurs projets de développement. Derrière cette préférence se cache un besoin légitime de proximité, de communication fluide et de maîtrise du contexte réglementaire. Or, certains prestataires affichent une adresse à Paris tout en faisant réaliser l'intégralité du développement par des équipes délocalisées.
La sous-traitance n'est pas un problème en soi — à condition qu'elle soit transparente. Le red flag, c'est quand le prestataire esquive la question « qui va concrètement coder mon projet ? » ou quand les interlocuteurs en phase commerciale disparaissent après la signature pour être remplacés par des profils que vous n'avez jamais rencontrés.
Red flag 5 : L'absence de livrables intermédiaires
Un prestataire qui propose un planning avec une livraison unique au bout de trois ou six mois maximise son risque et le vôtre. Sans jalons intermédiaires, vous n'avez aucune visibilité sur l'avancement réel, aucune capacité de correction de trajectoire, et aucun moyen de détecter un dérapage avant qu'il soit trop tard.
Les projets qui réussissent fonctionnent par itérations courtes : des livrables fonctionnels toutes les deux à quatre semaines, démontrables et testables. Si votre prestataire résiste à cette approche, demandez-vous ce qu'il cherche à cacher.
Red flag 6 : Le turn-over en cours de projet
Rien ne détruit plus sûrement un projet que le remplacement de l'équipe en cours de route. Chaque changement de développeur entraîne une perte de contexte, un temps de remontée en compétence, et des incohérences dans le code. Un prestataire sérieux s'engage sur la stabilité de l'équipe et a mis en place des mécanismes (documentation, pair programming, revues de code) pour limiter l'impact d'un départ éventuel.
Posez la question directement : quel est votre taux de turn-over ? Que se passe-t-il si le développeur principal quitte le projet ? Quelle est votre politique de documentation pour assurer la continuité ? Les réponses — ou l'absence de réponses — sont très révélatrices.
Red flag 7 : La résistance à l'audit et au transfert de compétences
Un prestataire qui refuse de vous donner accès au repository Git, qui ne documente pas son code, ou qui rend le transfert de compétences aussi difficile que possible cherche à créer une dépendance artificielle. C'est l'exact opposé de la confiance.
Un partenaire sain considère que votre autonomie progressive est un objectif, pas une menace. Il documente, il forme, il rend le code lisible et maintenable par quelqu'un d'autre. Sa valeur réside dans sa capacité à délivrer, pas dans le verrouillage de son client.
La grille d'évaluation en 10 critères
Comment noter objectivement un prestataire
L'évaluation d'un partenaire tech ne peut pas reposer uniquement sur l'intuition ou sur la qualité de la présentation commerciale. Voici une grille structurée pour objectiver votre décision.
| Critère | Poids | Questions clés | Score (/5) |
|---|---|---|---|
| Séniorité vérifiable de l'équipe | 15 % | CV consultables, profils LinkedIn, années d'expérience | |
| Références clients vérifiables | 15 % | Contact direct avec d'anciens clients, projets similaires | |
| Clarté de la proposition technique | 12 % | Spécifications détaillées, identification des risques | |
| Transparence contractuelle | 12 % | Réversibilité, propriété du code, SLA chiffrés | |
| Méthodologie projet | 10 % | Jalons, livrables intermédiaires, outils de suivi | |
| Compréhension métier | 10 % | Phase de découverte, questions pertinentes posées | |
| Politique de tests et qualité | 8 % | Tests automatisés, revue de code, CI/CD | |
| Gestion du changement de périmètre | 8 % | Process clair pour les évolutions, impact chiffré | |
| Stabilité de l'équipe | 5 % | Taux de turn-over, plan de continuité | |
| Communication et reporting | 5 % | Fréquence, format, interlocuteur dédié |
Un score global inférieur à 3/5 doit vous inciter à poursuivre votre recherche. Un score supérieur à 4/5 est le signe d'un prestataire structuré et mature. Aucun critère ne devrait individuellement descendre sous 2/5 — un seul point de défaillance grave peut compromettre l'ensemble du projet.
L'importance de la pondération
Les deux critères les plus fortement pondérés — séniorité de l'équipe et références clients — ne sont pas choisis au hasard. Ils sont les plus difficiles à simuler. Un prestataire peut rédiger une belle proposition commerciale avec peu d'effort. En revanche, produire des développeurs seniors avec des parcours vérifiables et des clients qui acceptent de témoigner spontanément exige des années de travail sérieux.
Les questions que personne ne pose (et qu'il faudrait poser)
Sur le modèle économique du prestataire
La santé financière de votre prestataire conditionne la pérennité de votre projet. Un prestataire en difficulté financière rogner sur la qualité, affectera des profils moins expérimentés que prévu, ou risque de disparaître en cours de projet. Selon l'APP (Agence pour la Protection des Programmes), la défaillance d'un fournisseur logiciel est un risque sous-estimé par la majorité des entreprises clientes.
Questions à poser sans hésiter :
- Quel est votre chiffre d'affaires et votre taux de croissance sur les trois dernières années ?
- Combien de clients représentent plus de 30 % de votre CA ? (Un prestataire trop dépendant d'un seul client est fragile.)
- Quelle est la taille de votre équipe permanente vs. les freelances mobilisés ponctuellement ?
- Êtes-vous rentable ? (La question paraît directe, mais un prestataire qui brûle du cash en attendant une levée de fonds n'est pas un partenaire stable.)
Sur la gestion des échecs
Tout prestataire honnête a connu des projets difficiles. La question n'est pas « avez-vous déjà échoué ? » — c'est « qu'avez-vous appris de vos échecs ? ». Un prestataire qui prétend n'avoir jamais rencontré de problème ment ou manque d'expérience.
Demandez des exemples concrets : racontez-moi un projet qui ne s'est pas déroulé comme prévu. Qu'est-ce qui a mal tourné ? Comment avez-vous géré la situation avec le client ? Qu'avez-vous changé dans vos processus depuis ? Les réponses à ces questions révèlent la maturité organisationnelle du prestataire bien plus efficacement que n'importe quelle certification.
Sur la propriété intellectuelle et la donnée
Dans le contexte de l'IA, la question de la propriété intellectuelle prend une dimension supplémentaire. Les modèles entraînés sur vos données métier, les pipelines de données construits pour votre cas d'usage, les prompts et configurations spécifiques — tout cela constitue un actif stratégique.
Vérifiez ces points avant de signer : qui est propriétaire du code source produit pendant le projet ? Les données d'entraînement restent-elles sous votre contrôle exclusif ? Le prestataire peut-il réutiliser les composants développés pour vous au bénéfice d'un concurrent ? Le contrat prévoit-il un plan de réversibilité complet avec transfert de l'ensemble des assets techniques ?
Le piège du « on verra bien » : structurer sa démarche de sélection
Phase 1 : Le cadrage du besoin (avant de contacter le moindre prestataire)
La première erreur que commettent les entreprises est de contacter des prestataires avant d'avoir clarifié leur propre besoin. Résultat : chaque prestataire reformule le besoin à sa manière, les propositions sont incomparables, et la décision repose sur celui qui a fait la meilleure présentation PowerPoint plutôt que sur celui qui apportera la meilleure réponse.
Avant de solliciter le marché, documentez a minima : le problème métier que vous cherchez à résoudre (pas la solution technique que vous imaginez), les utilisateurs finaux et leurs contraintes, les critères de succès mesurables, votre enveloppe budgétaire réaliste, et votre capacité de mobilisation interne pour accompagner le projet.
Phase 2 : La short-list et l'évaluation comparative
Sélectionnez trois à cinq prestataires maximum. Au-delà, le processus devient ingérable et vous finissez par comparer des propositions trop différentes pour être mises en regard. Utilisez la grille d'évaluation en 10 critères présentée plus haut pour structurer votre comparaison.
Exigez de chaque prestataire une phase de cadrage avant le chiffrage. Un prestataire qui chiffre sans cadrer ne comprend pas ce qu'il vend — ou ne cherche pas à comprendre. Cette phase de cadrage peut être facturée (quelques jours de travail), et c'est un investissement qui protège les deux parties.
Phase 3 : Le projet pilote
Quand c'est possible, démarrez par un périmètre réduit — un POC (Proof of Concept) ou un MVP (Minimum Viable Product) — avant de vous engager sur un projet de grande envergure. Ce pilote vous permet de tester en conditions réelles la qualité du code livré, le respect des délais, la fluidité de la communication, la réactivité face aux imprévus et la compatibilité culturelle entre vos équipes.
Un prestataire qui refuse un projet pilote en arguant que « ça ne vaut pas le coup pour un petit périmètre » révèle ses priorités : le volume de facturation plutôt que la construction d'une relation de confiance.
Spécificités de la sélection d'un partenaire IA
L'IA amplifie les risques du mauvais choix
Le développement IA ajoute des couches de complexité absentes des projets web ou mobile classiques : la qualité et la gouvernance des données, le choix et le fine-tuning des modèles, la gestion des biais algorithmiques, l'explicabilité des résultats, la conformité réglementaire (AI Act européen). Un prestataire généraliste qui « fait aussi de l'IA » depuis six mois ne maîtrise pas ces dimensions. La compétence IA se construit sur des projets livrés, pas sur des formations accélérées.
Les questions spécifiques à poser à un prestataire IA
Au-delà de la grille générale, ajoutez ces critères d'évaluation :
- Stack technique IA : Quels modèles et frameworks utilisez-vous ? Pourquoi ceux-là plutôt que d'autres ? (Un prestataire compétent justifie ses choix techniques en fonction du cas d'usage, pas par effet de mode.)
- Expérience données : Avez-vous une expertise en data engineering ou dépendez-vous d'un tiers pour la préparation des données ?
- Monitoring en production : Comment surveillez-vous la performance d'un modèle IA déployé ? (Un modèle IA se dégrade dans le temps — c'est normal — mais il faut le détecter et le corriger.)
- Conformité et éthique : Comment gérez-vous la question des biais ? Avez-vous une méthodologie d'audit algorithmique ?
- Souveraineté des données : Où sont hébergées les données d'entraînement et d'inférence ? Utilisez-vous des API tierces (OpenAI, Anthropic) et si oui, quelles données transitent par ces services ?
Le critère décisif : la séniorité en contexte IA
Dans le développement classique, un développeur junior encadré peut produire un travail acceptable. En IA, la marge d'erreur est beaucoup plus faible. Un mauvais choix d'architecture, un biais non détecté dans les données d'entraînement, ou une hallucination mal gérée dans un agent conversationnel peuvent avoir des conséquences métier sérieuses.
La séniorité des profils n'est pas un luxe dans un projet IA — c'est une condition de réussite. Recherchez des développeurs qui ont déjà mis en production des systèmes IA, pas seulement prototypé des démos.
Construire une relation de confiance dans la durée
Les 90 premiers jours : la période de vérité
Les trois premiers mois de collaboration sont décisifs. C'est pendant cette période que les processus se rodent, que les incompréhensions se révèlent, et que la culture de travail du prestataire se dévoile au-delà du discours commercial. Planifiez des points de revue formels à J+30, J+60 et J+90 pour évaluer la collaboration sur des critères objectifs.
Indicateurs à suivre pendant cette phase :
- Respect des délais sur les premiers livrables
- Qualité du code livré (revue technique indépendante si nécessaire)
- Réactivité aux demandes et aux questions
- Proactivité dans la remontée des risques et des problèmes
- Adéquation entre les profils annoncés et les profils réellement mobilisés
La transparence comme fondement
La confiance ne se décrète pas — elle se construit par l'accumulation de preuves. Un partenaire qui vous donne accès en temps réel au repository de code, qui partage un tableau de bord d'avancement actualisé, qui vous invite aux rétrospectives d'équipe, et qui vous alerte dès qu'un risque se matérialise crée les conditions d'une relation durable.
À l'inverse, un prestataire qui filtre l'information, qui minimise les problèmes, ou qui ne communique que pour annoncer les bonnes nouvelles construit une relation fragile qui explosera au premier obstacle sérieux.
Quand faut-il changer de prestataire
Malgré toutes les précautions, il arrive que la collaboration ne fonctionne pas. Les signaux qui doivent déclencher une remise en question : trois livrables consécutifs en retard sans explication crédible, un écart significatif entre les profils annoncés et les profils réels, une résistance systématique à la transparence (accès au code, documentation, reporting), ou une incapacité à intégrer les retours utilisateurs dans les itérations suivantes.
Rompre avec un prestataire en cours de projet est coûteux. C'est pourquoi les clauses de réversibilité et la documentation du code sont si critiques : elles rendent la transition possible sans repartir de zéro.
FAQ
Combien de prestataires faut-il consulter avant de choisir ? Trois à cinq prestataires constituent le bon équilibre. En dessous, vous manquez de points de comparaison. Au-dessus, le processus d'évaluation devient trop lourd et les propositions trop hétérogènes pour être comparées utilement. Concentrez votre énergie sur la qualité de l'évaluation plutôt que sur la quantité de consultations.
Un prestataire certifié (ISO 27001, CMMI) est-il automatiquement fiable ? Les certifications attestent d'une maturité organisationnelle, mais elles ne garantissent pas la qualité du livrable sur votre projet spécifique. Une certification ISO 27001 couvre la sécurité de l'information — elle ne dit rien sur la compétence technique des développeurs. Utilisez les certifications comme un filtre complémentaire, jamais comme un critère unique de sélection.
Faut-il privilégier un prestataire local ou accepter le remote ? Les données montrent que 65 % des entreprises françaises préfèrent un prestataire national. La proximité facilite la communication et le partage de contexte culturel. Cependant, la localisation compte moins que la qualité de la méthodologie de travail. Un prestataire distant mais parfaitement structuré (points réguliers, outils collaboratifs, documentation rigoureuse) surpassera un prestataire local désorganisé.
Comment vérifier la séniorité réelle des développeurs proposés ? Demandez les profils LinkedIn ou GitHub des développeurs affectés à votre projet. Vérifiez la cohérence entre les années d'expérience annoncées et le parcours réel. Posez des questions techniques lors d'un entretien de cadrage — un développeur senior explique des concepts complexes simplement. Si le prestataire refuse cette transparence, considérez-le comme un red flag majeur.
Quel budget prévoir pour une phase de cadrage avant le développement ? Une phase de cadrage sérieuse représente entre 3 et 8 jours de travail selon la complexité du projet, soit entre 2 500 € et 6 000 € HT. C'est un investissement qui réduit drastiquement le risque de dérapage. Les prestataires qui offrent le cadrage « gratuitement » le financent en gonflant le devis de réalisation — ou en bâclant cette étape critique.
Que faire si le prestataire choisi ne respecte pas ses engagements après signature ? Activez immédiatement les mécanismes contractuels prévus : notification formelle de non-conformité, référence aux SLA, déclenchement des pénalités si applicables. Documentez chaque défaillance par écrit. Si la situation ne s'améliore pas après un plan d'action correctif à 30 jours, préparez la transition vers un autre prestataire en vous appuyant sur les clauses de réversibilité.
AI Coder Squad : choisir un partenaire tech, c'est choisir une équipe
Les critères détaillés dans cet article — séniorité vérifiable, transparence contractuelle, méthodologie rigoureuse — ne sont pas des idéaux théoriques. Ce sont les standards qu'une entreprise de développement sérieuse applique au quotidien, projet après projet.
AI Coder Squad conçoit des applications sur mesure et des agents IA pour les entreprises qui veulent aller vite sans sacrifier la qualité — avec des développeurs senior et une approche propulsée par l'IA.
→ Démarrez votre projet et découvrez comment AI Coder Squad peut accélérer votre prochaine réalisation.