Infographie — Six équipements que Teams Phone ne remplace pas et ce qu'il leur faut

La conversation se tient dans à peu près toutes les organisations équipées de la suite Microsoft. « Nous avons déjà Teams, tout le monde s’en sert, on bascule la téléphonie dessus et le dossier fin du cuivre est clos. » La première partie est souvent une excellente idée. La seconde est fausse — et c’est une erreur qui se découvre après la coupure, quand plus rien ne peut être fait dans l’urgence.

La raison tient en une phrase : Teams traite la voix des personnes, pas celle des machines.

Ce que Teams fait très bien

Il ne s’agit pas de démolir une solution qui a de vraies qualités. Pour la téléphonie des collaborateurs, Teams règle élégamment plusieurs problèmes à la fois : un numéro qui suit la personne plutôt que le bureau, la continuité entre l’ordinateur, le mobile et le poste, la messagerie et la visioconférence dans le même outil, l’annuaire déjà à jour. Pour une organisation dont les salariés se déplacent, c’est souvent la bonne réponse. Les trois manières de raccorder Teams au réseau téléphonique — et leurs implications — sont détaillées dans Teams Phone : les trois voies et dans le principe et les prérequis de Teams Phone.

Ce que Teams ne fait pas du tout

Aucun des équipements suivants ne sait dialoguer avec Teams. Ils attendent une prise téléphonique classique, ou un module qui parle au réseau mobile. Rien d’autre.

Le transmetteur d’alarme qui appelle le centre de télésurveillance (voir ici).
Le dispositif d’appel d’urgence de l’ascenseur, qui doit joindre un service d’assistance depuis la cabine (détail ici).
Le terminal de paiement ancienne génération raccordé à la prise murale (les solutions).
Le fax, quand il doit être conservé pour de vraies raisons métier (comment faire).
Le portail, l’interphone, la télégestion, la télérelève, et tout ce que l’on découvre en faisant l’inventaire des usages sur lignes analogiques.

Ces équipements ne disparaissent pas parce qu’on a modernisé la téléphonie des bureaux. Ils continuent d’exister, branchés sur des lignes qui, elles, vont être coupées.

Trois questions avant de dire « on passe sur Teams »

Un : quelles de mes lignes servent à des machines ? C’est l’inventaire, et il n’y a pas de raccourci. Tant qu’il n’est pas fait, la décision « tout sur Teams » repose sur une hypothèse invérifiée. L’expérience montre qu’on trouve presque toujours plus de lignes techniques que prévu — et que personne ne sait à quoi sert la dernière.

Deux : que se passe-t-il quand le lien tombe ? Teams est un service en ligne : sans accès internet, il n’y a plus de téléphonie du tout. L’ancien autocommutateur, lui, continuait souvent d’assurer les appels internes. Ce n’est pas rédhibitoire, mais cela déplace la question vers la solidité de l’accès et son éventuel secours — voir la résilience de la voix sur IP et le secours de lien. Et n’oubliez pas le cas de la panne de courant, traité dans mon téléphone marchera-t-il sans électricité.

Trois : comment sont acheminés les appels d’urgence ? Avec une téléphonie où le numéro suit la personne plutôt que le lieu, la question de la localisation se pose sérieusement — et elle se traite au moment de la conception, pas après. Le sujet est développé dans les appels d’urgence depuis une ligne IP.

L’architecture qui fonctionne

Elle est simple à énoncer : deux chemins séparés, assumés comme tels.

D’un côté, Teams pour les personnes : postes, mobiles, salles de réunion, standard d’accueil, renvois. De l’autre, une réponse propre pour les machines : selon les cas, un boîtier qui recrée des prises analogiques raccordé à un trunk local — dont le principe et les limites sont expliqués dans la passerelle pour équipement analogique — ou, pour les équipements de sécurité, un module autonome sur réseau mobile, généralement préférable parce qu’il ne dépend ni de votre box ni de votre abonnement bureautique.

La tentation de tout faire transiter par le même canal est compréhensible — un fournisseur, une facture. Elle est mauvaise conseillère ici : un ascenseur et une réunion d’équipe n’ont pas les mêmes exigences de continuité, et les faire dépendre du même lien revient à aligner leur fiabilité sur celle du maillon le plus fragile.

Deux projets, une seule échéance

Il faut enfin séparer clairement les calendriers. Le passage à Teams est un projet de transformation : il se décide, se teste, s’accompagne, et il n’a pas de date imposée. La fin du cuivre est une échéance subie : elle tombe à une date que vous ne choisissez pas.

Les mener ensemble est possible et souvent judicieux — c’est l’occasion naturelle. Mais faire dépendre le traitement de vos équipements critiques de l’avancement d’un projet de transformation est risqué : si le déploiement Teams prend du retard, ce sont vos alarmes qui se retrouvent sans solution à la date de coupure. La règle de prudence est donc de traiter les machines en premier et indépendamment, puis de dérouler le projet Teams à son rythme. La méthode de séquencement est décrite dans migrer avant la coupure.

Cet article donne des repères généraux à visée d’information. Les capacités exactes de votre abonnement et le fonctionnement de vos équipements doivent être vérifiés auprès de votre prestataire et des fournisseurs concernés.

💡 Combien de vos lignes servent à des machines ? C’est la question qui décide de votre architecture. L’état des lieux fait ce tri, et le calendrier de fermeture vous dit de combien de temps vous disposez.