Lync 2010 : Les 5 conseils de développement

Pour construire une application ou élaborer un cahier des charges répondant à des attentes précises, voici les cinq conseils que je peux vous donner :

Conseil n°1 : Identifier les fonctionnalités attendues pour utiliser la bonne API

Comme présenté dans la partie précédente, Lync possède 4 API capables d’interagir à plusieurs niveaux. Certaines d’entre elles peuvent être utilisées aussi bien sur la partie cliente que serveur.

Il est donc indispensable de déterminer les objectifs de l’application : faciliter la communication entre les équipes produit ou avec les clients à partir de l’application métier, identifier facilement l’interlocuteur pour créer un accueil téléphonique plus convivial, optimiser la distribution des appels pour que l’interlocuteur échange toujours avec le même opérateur, etc …

Les contraintes techniques sont également à mettre dans la balance : Si l’application doit réaliser des actions à la place d’un utilisateur sans que celui-ci ne soit connecté, alors je privilégierais le SDK UCMA à la place du Lync 2010 (Pour rappel, cette API utilise la connexion du client Lync sur le poste).

Le but et les spécifications techniques sont définis et d’autres objectifs s’ajouteront à votre réflexion. A partir de ces informations, les API sont identifiables.

Conseil n°2 : construire votre « scénario de communication »

Dans le cas d’un projet gérant une partie d’un flux de communication, un « scénario de communication » peut être établi. Formaliser ce scénario est indispensable et permet d’aider à la compréhension afin de créer une application stable et fiable.

C’est dans ce scénario que des données spécifiques sont précisées. Prenons l’exemple d’une application IVR (Interactive Voice Response) : le numéro de téléphone est identifié à partir du format E164, chaque appel est tracé dans une table spécifique, si aucun numéro n’est identifié l’utilisateur doit choisir son département à l’aide des touches de son téléphone ou par reconnaissance vocale.

Toutes les actions réalisées par le code sont décrites étape par étape. En cas d’erreur ou de problème, une solution de contournement est spécifiée.

Conseil N°3 : Décomposez votre scénario en « scène »

Chaque étape ou action de votre application doit être décomposée en scène. Le travail du développeur sera facilité et vous obtiendrez le résultat attendu :

• L’utilisateur est capable de démarrer une conférence avec toutes les personnes de l’équipe. L’action est démarrée par un clic sur un bouton présent sur la fiche produit.

• L’interlocuteur est identifié par son numéro de téléphone (Format E164).

• La fiche du client est affichée automatiquement lorsqu’un opérateur décroche.

Cette méthode reprend le principe du développement agile « SCRUM ». Chaque scène est testée puis livrée pour valider et ne pas remettre en question le « scénario de communication »

Exemple :
1.    Créer l’application sur le serveur Lync
2.    Configurer l’agent pour recevoir un appel de l’extérieur
3.    Accepter l’appel
4.    Jouer la musique d’attente
5.    Récupérer les informations du contact à partir de la base de données

Conseil N°4 : Construire une équipe polyvalente

Ce type de développement est à mi-chemin entre les compétences d’infrastructure et de développement. L’équipe élaborée pour ce type de projet doit avoir la double compétence : des ingénieurs IT pour connaitre les différents rouages de Lync, et des développeurs maitrisant le langage et les API pour construire une application performante.

Exemple : J’ai eu l’occasion de travailler avec un développeur possédant peu de connaissance en IT. Le projet n’a jamais été finalisé car le temps de formation sur la partie infrastructure était trop important. L’IT est généralement perçu comme du « next, next, next » pour les développeurs. 😉

Conseil N°5 : Développer une application respectant les standards

Il est important d’avoir à l’esprit que le développement sur des plateformes comme Lync doit respecter des standards pour ne pas se retrouver avec une refonte totale lors de la nouvelle mise à jour mineure ou majeure.

D’autant plus que le « lifecycle » de Lync est particulièrement court : OCSR2 en 2008, Lync 2010 en 2010. Lync 2013 est en preview actuellement, deux ans seulement après la sortie de la version 2010.

Quelques actions sont nécessaires pour porter les applications vers 2013. Si les bonnes pratiques et les préconisations sont respectées, l’opération ne devrait pas poser de problème. Dans le cas contraire, il est possible qu’une partie de l’application (ou la totalité) doit être ré implémentée.

Maintenant, à vous de jouer !